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


یکی دیگر از خدمات ما طراحی وب سایتهای واکنشگرا یا Responsive با کیفیت بالا می باشد. برای طراحی این وب سایتها از تکنولوژیهای روز دنیا استفاده می شود.


       
صفحه اصلی  |  فروشگاه ما  |  استخدام  |  نرم افزار مدیریت برنامه غذایی رستوران ها  |  seo تضمینی اصفهان  |  ثبت نام  |  طراحی وب سایت در اصفهان  |  برنامه نویسی اصفهان  |  انجام پروژه های پایگاه داده SQL Server  |  انجام پروژه مهندسی نرم افزار  |  انجام پروژه های مالتی مدیا بیلدر  |  در مورد ما  |  انجام پروژه های اکسس Microsoft access  |  نمونه پروژه ها  |  ارتباط با ما  |  اخبار و مقاله  |  انجمن رفع اشکالات مشتریان
برجسته ترین ها
گروه های مقاله ها
HyperLink


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

 6-9-7 الگوی رابطه برای پروژه بانکداری

در جدول 6-25، یک نمودار E-R برای پروژه بانکداری نشان داده ایم. گروه مشابه از الگوی رابطه که در زیر نشان داده می شود با استفاده از تکنیکهائی تولید می شود که قبلاً در همین فصل بیان شده است. زیرا کلید اولیه را در هر الگو رابطه خط کشیده ایم.
برنامه های ناشی از یک موجودیت قوی:
branch= (branch-name ,branch-city ,assets)
customer= (customer-id ,customer-name ,customer-street ,customer-city)
loan= (loan-number ,amount)
account= (account-number ,balance)
employee= (employee-id , employee-name ,telephone-number ,street- date)
الگوهای ناشی از یک صفت چند مقداری: (صفات حاصله را ارائه نمی کنیم.) آنها در یک دیدگاه یا تابع تعریفی خاص تعریف می شوند:
dependent-name=(employee-id, d-name)
الگوهای حاصل از یک گروه رابطه که شامل گروههای موجودیت قوی باشد:
Account- branch= (account-number ,branch-name)
loan- branch= (loan-number ,branch-name)
borrower= (customer-id ,loan-number)
depositor= (customer-id ,account-number)
cuts-banker= (customer-id ,employee-id ,type)
work-for= (worker-employee-id ,manager-employee-id)
الگوهای حاصل از یک گروه موجودیت ضعیف: (قابل ذکر است که جدول loan-payment در بخش 6-9-3-1 به صورت زائد نشان داده شد)
payment= (loan-number ,payment-number ,payment-date ,payment-amount)

الگوی حاصل از یک رابطه ISA :(از میان دو گزینه مطرح در بخش 6-9-5، ما اولین گزینه را انتخاب کرده ایم تا حساب هایی که حساب پس انداز و یا حساب جاری نیستند نیز در این الگو گنجانده شوند.)
Saving -account= (account-number ,interest-rate)
Checking-account= (account-number ,overdraft-amount)
به عنوان تمرین محدودیت های کلید خارجی مناسبی را برای مثال بالا ایجاد کنید.


6-10 جنبه های دیگر طراحی پایگاه داده
بحث گسترده ما درمورد طراحی برنامه در این بخش، ممکن است این تصور اشتباه را ایجاد کند که طراحی الگو تنها بخش طراحی پایگاه داده است. در حقیقت چندین مسئله دیگر وجود دارد که در فصلهای بعد بطور کامل توضیح داده می شود و در اینجا فقط بطور خلاصه بررسی می شوند.

6-10-1 محدودیت داده ها و طراحی پایگاه داده رابطه ای
انواع مختلف محدودیت داده را ملاحظه کرده ایم که با استفاده از SQL می توان بیان کرد و شامل محدودیت های کلید اولیه، محدودیت های کلید خارجی، محدودیت های کنترلی، ترکیبات است.  محدودیت ها در برآوردن اهداف زیادی مفید هستند. که بدیهی ترین آن، خود کارکردن شرایط یکنواخت است. با نشان دادن محدودیت ها در زبان توصیف داده SQL، طراح قادر است تایید کند که خود سیستم پایگاه داده، این محدودیت ها را بکار می برد که این کار بهتر از اتکا به هر برنامه کاربردی برای بکار بردن محدودیت ها است. همچنین یک پایگاه مرکزی برای به روز کردن محدودیت ها و افزایش موارد جدید فراهم می کند.
مزیت دیگر بیان واضح و صریح محدودیت ها این است که بعضی از محدودیت ها در طراحی برنامه ارتباطی پایگاه داده مفید هستند و به عنوان مثال اگر بدانیم که یک شماره امنیت ملی، یک شخص خاص را مشخص می کند، می توانیم از این شماره برای اتصال به داده های مربوط به آن شخص استفاده کنیم حتی اگر این داده ها در رابطه های چند مقداری ظاهر شوند. که این موضوع با، مثالاً، رنگ چشم که یک خصوصیت منحصر به فرد نیست، تفاوت دارد. رنگ چشم را برای اتصال به داده های مربوط به یک شخص خاص در رابطه نمی توان به کار برد زیرا داده های آن شخص را نمی توان از داده های مربوط به افراد دیگری به افراد دیگری با همان رنگ چشم تشخیص داد.
در بخش 6-9، ما یک گروه الگو رابطه برای یک طرح E-R خاص ایجاد کردیم که این عمل با استفاده از محدودیت های تعیین شده در طرح صورت گرفت. در فصل 7، این طرح و موارد مربوط به آن را مرتب و گروه بندی می کنیم و نشان می دهیم چگونه می تواند به طراحی الگوی رابطه ای پایگاه داده کمک کند. شیوه صحیح طراحی پایگاه داده رابطه ای به ما امکان می دهد زمانیکه را که یک طرح خاص، مناسب و صحیح است بطور دقیق نشان دهیم و طرح های ضعیف را به طرح های مناسبتری تبدیل کنیم. ما خواهیم دید که فرایند، آغاز با طراحی یک رابطه- موجودیت و ایجاد برنامه رابطه از آن طرح به صورت الگوریتمی، شروع خوبی برای فرایند طراحی است.
محدودیت های داده در تعیین ساختار فیزیکی داده، موثر و مفید هستند ونیز ممکن است برای ذخیره سازی داده هایی که با یکدیگر ارتباط نزدیکی دارند، در مجاور و نزدیکی هم در ورودی دیسک مفید باشند تا از این طریق دسترسی به اطلاعات دیسک موثر و آسان باشد. زمانیکه فهرست بندی براساس کلید اولیه است، ساختار فهرست بندی خاصی موثر است.
هر وقت که پایگاه داده به روز می شود، اجرای محدودیت ها، به صورت بالقوه به درجه بندی بالایی از کارآیی می رسد. برای هر بار به روز شدن، سیستم باید همه محدودیت ها را چک کند و روز شدنی که
محدودیت ها را قبول نمی کند، رد شود و یا ترکیبات مناسبی صورت گیرد. اهمیت معایب این کارایی نه تنها به تکرار به روز شده بستگی دارد بلکه به نحوه طراحی پایگاه داده هم بستگی دارد. در حقیقت کا آمدی تست انواع خاصی از محدودیت ها، جنبه مهمی از مبحث طراحی برنامه رابطه پایگاه داده در فصل 7 است.


6-10-2 الزامات کاربردی: پرس وجوها، کارایی
کارایی سیستم پایگاه داده، جنبه مهمی از سیستم اطلاعاتی پروژه است، این کارایی نه تنها به استفاده موثر علوم کامپیوتری و سخت افزار ذخیره سازی مورد استفاده، مربوط می شود بلکه به مهارت افرادی که با سیستم ارتباط دارند ونیز به کارکرد فرایندهایی که تحت تأثیر اطلاعات پایگاه داده هستند، مربوط می شود.
دو معیار مهم اندازه گیری برای کارایی وجود دارد:
خروجی: تعداد پرس وجو یا به روز کردن (اغلب تبادل متقابل نامیده می شود) که بطور متوسط در هر واحد از زمان می تواند انجام شود.
زمان عکس العمل: مدت زمانی است که یک عکس العمل خاص از آغاز تا پایان در شرایط معمولی یا در بدترین شرایط انجام می شود.
سیستم هائی که بسیاری از فعل و انفعالات را به صورت جمعی انجام می دهند، بر دارا بودن خروجی بالا تمرکز می کنند. سیستم هائی که با مردم و سیستم های دقیق، رابطه دارند اغلب روی زمان عکس العمل تمرکز می کنند. این دو معیار اندازه گیری با هم متفاوت هستند. خروجی بالا ناشی از کاربرد زیاد اجزا سیستم است. این چنین کارکردهایی ممکن است باعث شود که بعضی فعل و انفعالات تا زمانیکه بتوانند بطور موثری انجام شوند، به تاخیر بیافتد. این فعل و انفعالات تاخیری، دارای زمان عکس العمل خوبی نیستند.
اکثر سیستمهای پایگاه داده تجاری، از نظر تاریخی بر خروجی متمرکز شده اند، با این حال طیف وسیعی از برنامه های کاربردی شامل برنامه های کاربردی web-based و سیستم های اطلاعاتی ارتباط از راه دور نیاز به زمان عکس العمل مناسبی در شرایط معمولی و در شرایط سخت دارند.
درک انواع پرس وجو انتظار می رود به فرایند طراحی کمک کند. پرس و جوهایی که شامل الحاق جایی است یک الحاق مورد نیاز است، مدیر پایگاه داده ممکن است ایندکسی ایجاد کند که ارزیابی آن مجموعه را تسهیل می کند. برای پرس وجو اگر چه شامل یک الحاق باشد یا خیر، ایندکس را برای تسریع در ارزیابی بخش اسنادی که احتمالاً بوجود می آیند، می توان ایجاد کرد. جنبه دیگر پرس و جو که بر انتخاب فهرست ها تاثیر می گذارد، ترکیب نسبی از به روز شدن و عملکردها است. در حالیکه یک ایندکس ممکن است به پرس وجو سرعت بخشد، همچنین به روز شدن هایی را نشان می دهد که باید کارهای بیشتری را انجام دهند تا صحت و درستی ایندکس را حفظ کنند.


6-10-3 الزامات کنترل
محدودیت های کنترلی بر طراحی پایگاه داده مؤثر است، به علاوه به دلیل اینکه SQL امکان دسترسی را بر اساس بخش های طرح پایگاه داده به کاربران می دهد. یک الگوی رابطه ای ممکن است به دو یا چند برنامه تقسیم می شود تا اعطای حق دسترسی در SQL تسهیل شود. برای مثال، پرونده یک کارمند ممکن است شامل داده هایی در رابطه با لیست حقوق، کارکردهای شغلی، و مزیت های پزشکی باشد. از آنجائیکه ممکن است واحدهای اجرایی مختلف پروژه، هر کدام از این نوع داده ها راکنترل کنند، برخی از کاربران مایلند که به لیست حقوق دسترسی داشته باشند در صورتیکه نیازی به قسمت های دیگر مثل داده های شغلی و یا داده های پزشکی ندارد. اگر همه این داده ها در این جدول باشد. اگر چه دسترسی به بخش دلخواه ممکن و شدنی است، اما مشکل و سخت است. زمانیکه داده ها در داخل سیستم در یک شبکه کامپیوتری پخش می شوند، تقسیم اطلاعات با این شیوه، اهمیت بیشتری پیدا می کند، موضوعی که در فصل 22 بررسی می کنیم.

6-10-4 جریان داده ها
برنامه کاربردی پایگاه داده، اغلب قسمتی از پروژه کاربردی بزرگتری است که نه تنها با سیستم پایگاه داده بلکه با برنامه های کاربردی تخصصی مختلف هم رابطه دارد. برای مثال، در یک شرکت تولیدی، سیستم نرم افزاری CAD   ممکن است به طراحی محصولات جدید کمک کند. سیستم CAD ممکن است داده ها را از پایگاه داده از طریق گزارش SQL انتخاب کند، روی داده ها کار می کند و شاید با یکی از طراحان این محصول ارتباط برقرار کند و سپس، پایگاه داده را به روز می کند. در طی این فرایند، کنترل داده ها در بین بسیاری از طراحان و سایر مردم انجام می شود. به عنوان مثال دیگر، گزارشی از هزینه یک سفر را در نظر بگیرید. یک کارمند که از سفر کاری برگشته است، این گزارش را تهیه می کند (احتمالاً بوسیله یک بسته نرم افزاری خاص) و بعد از آن برای مدیر و شاید مقامات بالاتر فرستاده می شود و بالاخره به قسمت حسابداری برای پرداخت می رود، (که باعث می شود با سیستمهای اطلاعاتی حسابداری پروژه مرتبط شود.)
اصطلاح workflow به ترکیب داده ها و کارهای مرتبط با فرایندهایی مانند مثال های قبل اشاره    می کند. workflow با سیستم پایگاه داده مرتبط می شود در حالیکه بین کاربران در جریان است. و کاربران کارهای خود را در workflow انجام می دهند. علاوه بر داده هایی که workflow انجام می دهد، پایگاه داده ممکن است که داده هایی را در مورد خود workflow ذخیره سازی کند که شامل وظایفی که workflow را ایجاد می کند. و نیز نحوه ارسال آن به کاربران می شود. بنابراین، workflow یک سری از به روز کردن ها و پرس وجوها را برای پایگاه داده تعیین می کند که ممکن است به عنوان بخشی از فرایند طراحی پایگاه داده محسوب شود. همچنین، مدل سازی پروژه ما را ملزم می کند که نه تنها مفهوم پایگاه را بدانیم، بلکه مراحل کارهای تجاری که از این داده ها استفاده می کنند را نیز بدانیم.

6-10-5 موضوعات دیگر در طراحی پایگاه داده
معمولاً، طراحی پایگاه داده، فقط در یک زمان و یک بار صورت نمی گیرد. نیاز یک سازمان، بطور مداوم افزایش می یابد و داده هایی که نیاز به ذخیره سازی دارند نیز به همین طریق افزایش می یابد. در طی مراحل اولیه طراحی پایگاه داده یا در طی ایجاد یک برنامه کاربردی، ممکن است طراح متوجه تغییرات مورد نیاز برنامه در سطح فیزیکی، مفهومی شود. تغییرات در برنامه بر تمام جنبه های کاربردی پایگاه داده تاثیرگذار است. یک طراحی مناسب از پایگاه داده، نیازهای آینده یک سازمان را بیش بینی می کند و برنامه را به شیوه ای طراحی می کند که با پیدایش نیازهای جدید، کمترین تغییرات مورد نیاز باشد.
این مساله حائز اهمیت است که بین محدودیت های بنیادی و محدودیت هایی که امکان تغییر در آنها وجود دارد، تفاوت قائل شدیم. برای مثال، محدودیت شماره شناسایی مشتری که یک مشتری خاص را مشخص می کند، محدودیتی بنیادی است. از طرف دیگر، ممکن است سیاست کاری یک بانک به گونه ای باشد که یک مشتری فقط یک حساب داشته باشد که ممکن است این سیاست بعدها تغییر یابد. طراحی پایگاه داده که فقط اجازه یک حساب برای مشتری می دهد، در صورت تغییر سیاست بانک، نیازمند تغییرات اساسی است. این چنین تغییراتی نباید نیازمند تغییرات اساسی در طراحی پایگاه داده باشند.
به علاوه، پروژه ای که در آن پایگاه داده، به ارتباط احتمالی با سایر پروژه ها کمک می کند و بنابراین ممکن است چندین پایگاه داده نیازمند ارتباط باشند. تبادل اطلاعات در بین برنامه های مختلف، مسئله مهمی در برنامه های کاربردی جهان واقعی است راه حل های مختلفی برای این مساله پیشنهاد شده است. مدل داده XML، که در فصل 10 بررسی می شود، به طور گسترده ای برای ارائه داده ها در زمان تبادل آنها در بین برنامه های مختلف، استفاده سرانجام، این موضوع اهمیت چندانی ندارد که طراحی پایگاه داده، از دو جنبه یک فعالیت، انسان گرا است: کاربران نهایی این سیستم مردم هستند. (حتی اگر یک برنامه کاربردی در بین پایگاه داده و کاربران نهایی قرار دارد) و طراح پایگاه داده نیاز به ارتباط گسترده با کارشناسان در زمینه این برنامه دارد والزامات داده های برنامه کاربردی را درک کند. تمام کسانی که با داده ها در ارتباط هستند، نیازها و اولویت هایی دارند که باید بصورت مناسبی برای طراحی پایگاه داده،    مد نظر قرار گیرد تا در پروژه موفق شوند.

 


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

HyperLink

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