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


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


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


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

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

دو فصل ابتدای این بخش به طراحی الگو های پایگاه داده می پردازد. مدل موجودیت-رابطهE-R که در فصل 6 توصیف می شود یک مدل سطح بالای داده است.این مدل به جای آنکه همه داده ها را در جدولها بیان کند، بین اشیای اصلی تمایز قائل می شود، که موجودیت و رابطه میان این اشیا نامیده می شود. این مدل به عنوان اولین مرحله در طراحی الگوی پایگاه داده ها بکار میرود.
طراحی پایگاه داده رابطه ای –طراحی الگوی رابطه ای- در بخشهای قبلی به طور خلاصه آمده است. البته اصولی وجود دارندکه می توان از آنها برای تشخیص طراحی های پایگاه داده خوب از پایگاه داده بد استفاده کرد. این اصول را از طریق چند «فرم نرمال» که بین احتمال ناسازگاری و کارآیی پرس و جوهای معین تفاوت قائل می شوند، سازماندهی می کنیم. فصل 7  طراحی فرمال الگوهای رابطه ای را شرح می دهد.
طراحی محیط یک برنامه کاربردی پایگاه داده کامل که با نیازهای سازمان در حال مدل بندی شدن مواحه است، توجه به گروه گسترده تری از اعمال داردکه بسیاری از آنها در فصل 8 پوشش داده می شوند.این فصل به توصیف واسط کاربر های Web-base برای پایگاههای داده می پردازد و بحث های پیشین ما درباره یکپارچگی و امنیت را وسعت می دهد.


فصـل 6
طراحی پایگاه داده مدل E-R

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

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

6-1-1 مراحل طراحی
طراح پایگاه داده که نیاز های کاربردی را می شناسد در برنامه های کاربردی جزئی می توانند دقیقا درباره روابطی که باید ایجاد شود، نسبتهای آنها و محدودیتهای این روابط تصمیم گیری کنند. با این حال چنین تصمیم گیری دقیقی در مورد برنامه های کاربردی دنیای واقعی مشکل است، زیرا اغلب آنها بسیار پیچیده هستند. غالبا هیچ کس همه اطلاعاتی که یک برنامه کاربردی نیاز دارد را نمی داند. طراح پایگاه داده باید در تماس با کاربران، الزامات و نیازهای این برنامه ها را بشناسد و آنها را در حالتی عالی و مناسب ارائه کند تا کاربران بتوانند آنها را بشناسند و بعد این الزامات را در سطوح پایین تر طرح پیاده کنند. یک مدل داده در سطح بالا با ارائه چهارچوب مفهومی به طراح پایگاه داده کمک می کند که در حالتی سیستماتیک ، داده های مورد نیاز کاربران پایگاه داده و ساختار آن که این نیازها  را تامین می کند را مشخص کند.
اولین فاز طراحی پایگاه داده ، مشخص کردن نیاز داده کاربران پایگاه داده است. طراح پایگاه داده با تماس با کارشناسان این حوزه و کاربران این وظیفه را انجام دهد. نتیجه این حالت روشن شدن نیازهای کاربران است. در این بخش، خود را به توصیف نوشتاری نیازهای کاربران محدود می کنیم که به این موضوع در بخش 6-8-2 می پردازیم.
در مرحله بعد طراح، یک مدل داده انتخاب می کند و با استفاده از مفاهیم این مدل انتخابی الزامات آنرا به چهارچوب مفهومی پایگاه داده تبدیل می کند. این چهار چوب کلی که در حالت طراحی مفهومی ایجاد می شود مفهوم دقیقی را از این پروژه ارائه می دهد.
مدل موجودیت - رابطه که ما در ادامه این فصل مورد مطالعه قرار می دهیم،  عموماً برای ارایه طراحی مفهومی مورد استفاده قرار می گیرد. در مدل موجودیت  رابطه، الگوی مفهومی موجودیتهای موجود در پایگاه داده، صفات موجودیت ها رابطه بین موجودیتها و محدودیت های صفات را مشخص می کند. مرحله طراحی مفهومی معمولا به ایجاد نمودار موجودیت رابطه نمایشگر الگوی گرافیکی منجر می شود.
طراح چهارچوب را مرور می کند تا مطمئن شود که همه الزامات داده بر طرف می شوند و در تضاد با هم نیستند. او همچنین می تواند طرح را برای برطرف کردن هرگونه موارد غیر ضروری بررسی و آزمایش کند. در این مرحله بجای تعیین جزئیات فیزیکی ذخیره سازی، بر روی توصیف داده ها و روابط آنها تمرکز می کند.
چهارچوب مفهوم کلی که بطور کلی ایجاد شده باشد، الزامات کاربردی و عملی پروژه را نشان می دهد. در توصیف الزامات عملی و مفید، کاربران نوع کاری را که بر روی داده ها انجام خواهد شد توصیف می کنند. کارهایی نظیر تطبیق دادن و یا به روز درآمدن داده ها، جستجو و پیدا کردن اطلاعات خاص و نیز حذف داده ها را می توان نام برد. در این مرحله از طراحی مفهومی، طراح می تواند برنامه اصلی را مرور کند تا مطمئن شود که آن برای الزامات کاربردی و عملی، مناسب است.
فرایند حرکت از یک مدل انتزاعی تا اجرای پایگاه داده، در دو مرحله طراحی پایانی ادامه می یابد.
o در مرحله طراحی منطقی، طراح چهارچوب، مفهومی پیشرفته را به اجرای مدل داده سیستم پایگاه داده متصل می کند که بعد مورد استفاده قرار خواهد گرفت. اجرای مدل داده معمولا˝ به صورت مدل داده رابطه ای است و این مرحله شامل استفاده از مدل موجودیت رابطه در چهارچوب رابطه ای است.
o در آخر، طراح از نتایج سیستم خاص چهاچوب پایگاه داده در حالت طراحی فیزیکی در مرحله بعد استفاده می کند که در آن خصوصیات فیزیکی پایگاه داده مشخص می شود. این خصوصیات شکل تنظیم فایلها و ساختار ذخیره سازی داخلی می شود. این موارد در فصل 11 مورد بحث قرار می گیرد.
بعد از ساخت برنامه کاربردی، چهارچوب فیزیکی پایگاه داده را به راحتی می توان تغییر داد. با این حال تغییر در ساختار چهارچوب منطقی مشکل تر است، زیرا ممکن است بر بعضی از مسائل و نکات جدید موجود بر کدهای کاربردی تاثیر بگذارند. بنابراین قبل از ساخت بقیه پایگاه داده کاربردی، دقت در اجرای مرحله طراحی پایگاه داده از اهمیت خاصی برخوردار است.

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

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

6-2-1 گروه موجودیت ها
یک موجودیت، چیز یا شیء در دنیای واقعی است که از دیگر اشیاء قابل تشخیص است. مثلا هر شخصی دریک پروژه یک موجودیت است که یک سری خصوصیات دارد و شاید ارزش بعضی از این خصوصیات، هویت آن موجودیت را مشخص می کند. برای مثال شخصی که کارت شناسایی دارد عددهای آن فقط هویت آن فرد را نشان می دهد. بنابراین شماره 9011-89-677 در کارت شناسایی فردی فقط هویت یک فرد خاص را مشخص می کند. به همین نحو وامها  را می توان مانند موجودیت هایی فرض کرد و شماره وام L-15 را در شعبه پری ریج  فقط یک موجودیت وام را مشخص می کند. یک موجودیت ممکن است مثل یک شخص یاکتاب، واقعی باشد یا اینکه انتزاعی وخیالی باشد. مثل وام، تعطیلات و یا یک مفهوم.
یک گروه موجودیت، یک سری موجودیت ها از یک نوع است که خصوصیات مشترکی دارند. به عنوان مثال گروهی از همه اشخاصی که مشتری یک بانک خاص هستند، به عنوان موجودیت گروه مشتری توصیف می شوند. به همین طریق احتمالا گروه موجودیت های وام نشان دهنده گروهی از تمام وام هایی است که توسط یک بانک خاص اعطا شده است. تک تک موجودیت هایی که یک گروه را  تشکیل می دهند، به عنوان وسعت گروه موجودیت نامیده می شوند. بنابراین تک تک مشتری های بانک وسعت گروه موجودیت مشتری هستند.
موجودیت گروهها نباید از هم گسیخته شوند برای مثال می توان گروه موجودیت های همه کارمندان یک بانک و گروه موجودیت های همه مشتری های بانک را مشخص کرد. یک موجودیت مشخص ممکن است هم مشتری و هم کارمند باشد یا هیچ کدام از اینها.
یک موجودیت با یک سری از صفات نشان داده می شود. صفات بیان کننده ویژگی هایی است که هر عضو یک گروه دارا می باشد. طراحی یک صفت برای یک گروه موجودیت نشان می دهد که پایگاه داده اطلاعات مشابهی درمورد هر موجودیت در گروه ذخیره می کند. با این وجود موجودیت ممکن است مقدار خاصی از هر صفت را داشته باشد. صفات احتمالی یک گروه مشتری عبارتند از شماره شناسایی مشتری- نام مشتری- نام خیابان مشتری- نام شهر مشتری. در زندگی واقعی صفات بیشتری مانند شماره خیابان- شماره آپارتمان- ایالت-کد پستی و کشور وجود دارد.که آنها را بدلیل ساده نگه داشتن مثال حذف می کنیم. صفات احتمالی برای وام عبارتند از شماره وام و مقدار آن .
هر موجودیت برای هر کدام از صفات خود یک شماره و عدد دارد. به عنوان مثال یک موجودیت مشتری خاص ممکن است شماره 3123 - 12- 321 ر ا به عنوان شماره شناسایی- جونز  را به عنوان نام مشتری- ماین  را به عنوان خیابان مشتری و هریسون  را به عنوان شهر مشتری خود داشته باشد.

شماره شناسایی مشتری برای تشخیص مشتری به کار می رود. در آمریکا در بسیاری از پروژه ها متوجه شدند که استفاده از شماره امنیت اجتماعی  یک شخص به عنوان صفتی که عدد آن فقط همان شخص را شناسایی می کند راحت و مناسب است. بطورکلی در پروژه ها باید برای هر مشتری یک شناسایی کننده خاص ایجاد کنند.
1000 L-17 harrison Main Jones 321-12-3123
2000 L-23 Rye North Smith 019-28-3746
1500 L-15 Harrison Main Hayes 677-89-9011
1500 L-14 Woodside Dupont Jackson 555-55-5555
 500 L-19 Rye North Curry 244-66-8800
 900 L-11 Princeton Nassau Williams 963-96-3963
1300 L-16 Pittsfield Spring Adams 335-57-7991
loan Customer
شکل 6-1 گروه موجودیت customer  و loan
بنابراین پایگاه داده شامل مجموعه ای از گروههای موجودیت  است که هر کدام شامل تعدادی موجودیت از همان نوع هستند. جدول 6- 1 قسمتی از یک پایگاه داده بانکی را نشان می دهد که شامل دو گروه موجودیت است: مشتری و وام
پایگاه داده برای پروژه بانکداری احتمالاً شامل تعدادی از دیگر گروههای موجودیت ها است. برای مثال بانکها علاوه برداشتن اطلاعات مشتریان و وامها، شماره حسابهایی ارائه می کنند که همراه صفت شماره حساب و شماره تراز نشان داده می شوند. همچنین اگر بانک شعبه های مختلفی دارد ما اطلاعاتی درباره همه شعبه های بانک نگه می داریم. هر گروه موجودیت ها احتمالاً توسط صفت های نام شعبه،شهر شعبه و منابع توصیف می شود.

 


تگها: پایگاه داده   پایگاه داده رابطه ای   زبان های رابطه ای   مدل موجودیت رابطه   
 

HyperLink

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