اصول طراحی پایگاه داده

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

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

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

در این مقاله

برخی از اصطلاحات پایگاه داده برای دانستن

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

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

طراحی پایگاه داده خوب چیست؟

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

بنابراین ، یک طراحی پایگاه داده خوب ، یکی از مواردی است که:

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

دسترسی به اطلاعات مورد نیاز برای پیوستن به اطلاعات موجود در جداول را در صورت لزوم فراهم می کند.

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

نیازهای پردازش و گزارش داده های شما را در بر می گیرد.

روند طراحی

فرایند طراحی شامل مراحل زیر است:

هدف از پایگاه داده خود را تعیین کنید

این به شما کمک می کند تا برای مراحل باقیمانده آماده شوید.

اطلاعات مورد نیاز را پیدا و سازماندهی کنید

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

اطلاعات را به جداول تقسیم کنید

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

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

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

کلیدهای اولیه را مشخص کنید

کلید اصلی هر جدول را انتخاب کنید. کلید اصلی ستونی است که برای شناسایی منحصر به فرد هر سطر استفاده می شود. یک مثال ممکن است شناسه محصول یا شناسه سفارش باشد.

روابط جدول را تنظیم کنید

به هر جدول نگاه کنید و تصمیم بگیرید که چگونه داده ها در یک جدول با داده های موجود در جداول دیگر مرتبط است. در صورت لزوم ، زمینه ها را به جداول اضافه کنید یا جداول جدیدی ایجاد کنید تا روابط را روشن کنید.

طرح خود را اصلاح کنید

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

قوانین عادی سازی را اعمال کنید

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

تعیین هدف از پایگاه داده خود

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

یافتن و سازماندهی اطلاعات مورد نیاز

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

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

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

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

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

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

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

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

پس از جمع آوری این اطلاعات ، شما برای مرحله بعدی آماده هستید.

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

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

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

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

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

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

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

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

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

تبدیل موارد اطلاعات به ستون ها

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

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

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

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

داده های محاسبه شده را درج نکنید

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

اطلاعات را در کوچکترین قسمت های منطقی خود ذخیره کنید

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

پس از تصفیه ستون های داده در هر جدول ، شما آماده انتخاب کلید اصلی هر جدول هستید.

مشخص کردن کلیدهای اولیه

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

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

یک کلید اصلی همیشه باید یک مقدار داشته باشد. اگر مقدار یک ستون در مقطعی غیرقابل توصیف یا ناشناخته باشد (مقدار گمشده) ، نمی تواند به عنوان یک مؤلفه در یک کلید اصلی استفاده شود.

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

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

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

1. ستونی که بر روی نوع داده AutoNumber تنظیم شده است ، اغلب یک کلید اصلی خوب را ایجاد می کند. هیچ دو شناسه محصول یکسان نیستند.

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

برای پایگاه داده فروش محصول ، می توانید یک ستون AutoNumber برای هر یک از جداول ایجاد کنید تا به عنوان کلید اصلی خدمت کنید: ProductID برای جدول محصولات ، سفارش برای جدول سفارشات ، جدول مشتری برای مشتریان و تهیه کننده جدول تهیه کنندگان.

ایجاد روابط جدول

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

1. اطلاعات در این فرم از جدول مشتریان تهیه می شود.

2. جدول کارمندان

3. جدول سفارشات.

4.. جدول محصولات

5.. و جدول جزئیات سفارش.

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

ایجاد یک رابطه یک به بسیاری

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

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

ستون تأمین کننده ID در جدول محصولات یک کلید خارجی نامیده می شود. یک کلید خارجی کلید اصلی یک جدول دیگر است. ستون تأمین کننده ID در جدول محصولات یک کلید خارجی است زیرا همچنین کلید اصلی در جدول تأمین کنندگان است.

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

ایجاد یک رابطه بسیار به بسیاری

رابطه بین جدول محصولات و جدول سفارشات را در نظر بگیرید.

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

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

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

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

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

جدول سفارشات و جدول جزئیات سفارش دارای یک رابطه یک به بسیاری است. هر سفارش می تواند بیش از یک مورد خط داشته باشد ، اما هر مورد خط فقط به یک سفارش وصل می شود.

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

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

پس از درج جدول جزئیات سفارش ، لیست جداول و زمینه ها ممکن است چیزی شبیه به این باشد:

ایجاد یک رابطه یک به یک

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

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

اگر دو جدول دارای یک موضوع یکسان باشند ، احتمالاً می توانید با استفاده از همان کلید اصلی در هر دو جدول ، رابطه را تنظیم کنید.

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

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

تصفیه طرح

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

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

همانطور که پایگاه داده اولیه خود را امتحان می کنید ، احتمالاً جایی برای بهبود پیدا خواهید کرد. در اینجا چند مورد برای بررسی وجود دارد:

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

آیا ستون های غیر ضروری هستند زیرا می توان آنها را از زمینه های موجود محاسبه کرد؟اگر می توان یک مورد اطلاعاتی را از سایر ستون های موجود محاسبه کرد - به عنوان مثال قیمت تخفیف محاسبه شده از قیمت خرده فروشی - معمولاً بهتر است فقط این کار را انجام دهید و از ایجاد ستون جدید خودداری کنید.

آیا به طور مکرر در یکی از جداول خود اطلاعات تکراری را وارد می کنید؟اگر چنین است ، احتمالاً باید جدول را به دو جدول تقسیم کنید که دارای یک رابطه یک به یک هستند.

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

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

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

آیا همه روابط بین جداول ، یا توسط زمینه های مشترک یا با جدول سوم نشان داده شده است؟روابط یک به یک و یک به یک به ستون های مشترک نیاز دارند. روابط بسیاری به بسیاری نیاز به جدول سوم دارد.

پالایش جدول محصولات

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

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

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

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

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

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

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

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

هر وقت می بینید گروه های تکرار شونده طرح را با چشم به تقسیم جدول به دو مورد بررسی می کنند. در مثال بالا بهتر است از دو جدول ، یکی برای تأمین کنندگان و دیگری برای محصولات ، که توسط Supplier ID مرتبط است استفاده کنید.

اعمال قوانین عادی سازی

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

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

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

اولین فرم طبیعی

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

دوم فرم عادی

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

شناسه سفارش (کلید اصلی)

شناسه محصول (کلید اصلی)

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

سومین فرم عادی

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

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

ProductId (کلید اصلی)

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