در توسینسو تدریس کنید

و

با دانش خود درآمد کسب کنید

آموزش کوئری (Query) گرفتن از SQL قسمت 8 : Normalization

در مقاله قبلی در خصوص ابتدا کمی در خصوص شیوه طراحی یک پایگاه داده معمولی صحبت کردیم ، سپس اشاره کردیم که بایستی تمامی موجودیت های خود را در قالب یک Table مجتمع کنیم و شروع کنیم به انجام فرآیند Normalization ، گفتیم که تا جاییکه امکان دارد نباید داده های تکراری یا بهتر بگوییم رکوردهای تکراری در Table های خود داشته باشیم و این هدف اصلی Normalization نیز می باشد ، به همین دلیل در سطح اول جدوال Orders و Products را از جدول اولیه خارج کردیم، سپس برای اینکه این جداول بتوانند به همدیگر متصل شوند از ساختار Primary Key و Foreign Key که توسط Order ID ایجاد شده بود استفاده کردیم که در واقع سطح اول یا حالت اول Normalization ما بود .

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

گام پنجم : ایجاد رابطه Many To Many با استفاده از یک Table میانی ( Join کردن Table ها )

طراحی بانک های اطلاعات در SQL سرور 2012

اگر به تصویر بالا توجه کنید متوجه می شوید که ما یک Table به نام Orders داریم که در آن یک Column به نام Customer ID یا شناسه مشتری وجود دارد. Customer ID در اینجا به عنوان کلید خارجی یا Foreign Key ها محسوب می شود که به Table ای به نام Customers اشاره می کند. با استفاده از این روش شما Table های Orders و Customers را به هم مرتبط کرده اید و زمانیکه یک مشتری یا customer یک سفارش یا Order را می دهد با استفاده از Customer ID ای که در جدول Orders وجود دارد دقیقا به Customer یا مشتری که اطلاعات کامل آن در آن وجود دارد اشاره خواهد کرد. با این روش شما دقیقا می توانید متوجه بشوید که چه مشتری چه سفارشی داده است و این Foreign Key وظیفه ارتباط این دو جدول را انجام می دهد. در همین جدول دقت کنید که Customer ID در جدول Customers به عنوان کلید اصلی یا Primary Key ما انتخاب شده است و این دقیقا مثال جامعی از رابطه یک به چند یا One To Many می باشد.

خوب حالا بیابید با هم یک تغییر بزرگتر در طراحی Table ها بدهیم ، خوب ما همچنان جدول Orders را خواهیم داشت اما یک جدول دیگر به نام Products به مجموعه جداول خود اضافه خواهیم کرد ، در این جدول ما اطلاعات محصولات خود را ذخیره سازی خواهیم کرد و همچنان هم تاکید می کنم که ذخیره سازی ما در قالب یک Table جداگانه انجام می شود. خوب اگر به تصویر پایین دقت کنید که در آن جدول Products ما ایجاد شده است متوجه خواهید شد که ما همچنان یک Column در این جدول به عنوان Name یا نام کالا داریم اما یک Column جدید به نام قیمت کالا یا List Price نیز به Table خود اضافه کرده ایم که در آن اطلاعات قیمت کالای ما ذخیره خواهد شد. در نهایت توجه کنید که ما یک Column به نام Product ID را همچنان داریم ، که این column در این Table در نقش Primary Key ما ایفای نقش خواهد کرد ، خوب مشکل ما از اینجا شروع می شود که ما قرار است جداول Orders و Products و Customers را در کنار هم قرار دهیم و به هم مرتبط کنیم .

خوب به نظر شما ما چگونه می توانیم این ارتباط را برقرار کنیم ؟ همانطور که از ابتدای مقالات هم اشاره کردیم یک Product می تواند چندین بار Order داده شود و از طرفی یک Order نیز می تواند شامل چندین Product باشد و این یعنی باید بین این جداول یک رابطه Many To Many برقرار شود ، قبلا هم اشاره کرده ایم که SQL سرور بصورت مستقیم نمی تواند رابطه های Many To Many را ایجاد کند و به همین دلیل ما مجبور با استفاده از یک Table میانی هستیم که بتواند به عنوان واسطه این جداول را به هم مرتبط کند. به تصویر زیر دقت کنید ، در اینجاست که Table ای به نام Order Details وارد مدار می شود. به Table های زیر دقت کنید.

Normalization در SQL سرور و طراحی پایگاه داده RDBMS

خوب در جدول Order Details قسمت Order ID به جدول Orders و قسمت Product ID به جدول Products مرتبط شده اند. خوب با استفاده از این روش شما می توانید اطلاعات کاملی در خصوص سفارش ها و کالاهای خود داشته باشید ، اگر به جدول Order Details نگاه کنید در رکورد اول مشاهده می کنید که مشخص است اولین سفارش ثبت شده ما یعنی Order ID = 1 به نوع محصول پوشک Molfix که Product ID = 1 است اشاره می کند و تعداد آن 5 عدد می باشد و قیمت هر واحد آن 10 هزار تومان و مجموع قیمت آنها که در Line Total نوشته شده است به 50 هزار تومان می رسد. البته در خصوص بسیاری از نکات که در این جداول وجود دارد در آینده بسیار صحبت خواهیم کرد اما در اینجا همین مقدار کفایت می کند. اما نقطه قوت این طراحی در کجا است ؟ چه اتفاقی می افتد اگر Sale Price یکی از Product های شما تغییر کند ؟

ما می خواهیم همیشه مطمئن شویم که قسمت محصول در زمانیکه سفارش یا Order داده شده است چقدر بوده است ؟ به همین دلیل است که ما قیمت محصول را در قسمت Sale Price در قالب یک Column جداگانه ذخیره می کنیم. همچین دقت کنید که ما در همین جدول یک محاسبه کوچک نیز انجام دادیم و Sale Price را در Quantity ضرب کردیم و نتیجه را در یک Column به نام Line Total ذخیره کردیم . این دقیقا همان چیزی است که شما باید در یک طراحی خوب Database در نظر داشته باشید.

خلاصه نکات در خصوص Table های Orders و Products

خوب Database نهایی که در بالا مشاهده می کنید را در نظر داشته باشید ، تقریبا تمامی فرآیند هایی که ما انجام داده ایم در این Table ها خلاصه شده اند. ما یک Table به نام Order Details ایجاد کردیم که دارای column هایی به نام Order ID یا شناسه سفارش ، Product ID یا شناسه کالا ، Quantity یا تعداد سفارش ، Sale Price یا قیمت فروش و در نهایت Line Total است که مجموع قیمت سفارش ها را در خود نگه می دارد ، این table دارای رابطه Many To Many است .

همچنین با ایجاد شدن این Table ما اطلاعات مربوط به Order ها را از Table ای که برای Product ها در نظر گرفته شده بود حذف کردیم و به جای آن در جدول Products یک Column جدید به نام List Price اضافه کردیم. اگر به جدول Order Details توجه کنید یک Column به نام Sale Price وجود دارد که نمایانگر قیمت فروش کالا است ، ما در عین حال یک Column دیگر در جدول List Price داریم که قیمت حال کالا را نمایش می دهد ، حال اگر قیمت امروز محصول عوض شود و ارزش ریالی آن زیاد شود شما بر اساس قیمت و تاریخ سفارش می توانید قیمت اولیه محصول را بدست بیاورید.

همچنین ما برای اینکه بتوانیم Query های ساده تری بگیریم یک Column به نام Line Total به Order Details اضافه کرده ایم. زمانیکه صحبت از Normalization سطح سوم یا فرم سوم می شود یک قانون وجود دارد که با این جمله بیان می شود : در Normalization سطح سوم هر ارزش یا Value یا مقدار بایستی وابسته به یک کلید یا Key باشد. این بدین معناست که یعنی column ای به نام Line Total وابسته به کلید های Column های دیگری مثل Quantity و Sale Price می باشد . البته در این مثال ما بر خلاف قانون Normalization کار کردیم و یک Column اضافه به جدول برای محاسبه مقدار اضافه کردیم. اما فراموش نکنیم که برخی اوقات برای اینکه بتوانیم کارایی Database خود را بیشتر کنیم مجبور هستیم Normalization را برعکس کنیم و فرآیند Denormalization را انجام دهیم. ITPRO باشید.

نویسنده : محمد نصیری

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

هرگونه نشر و کپی برداری بدون ذکر منبع و نام نویسنده دارای اشکال اخلاقی می باشد

#طراحی_table_های_sql #طراحی_دیتابیس_های_sql #آموزش_sql_server #آموزش_گام_به_گام_sql_سرور #آموزش_sql_سرور #آموزش_sql #آموزش_طراحی_sql_سرور #آموزش_گام_به_گام_query_گرفتن #join_کردن_table_ها_در_sql
عنوان
1 آموزش کوئری (Query) گرفتن از SQL قسمت 1 : معرفی SQL سرور رایگان
2 آموزش کوئری (Query) گرفتن از SQL قسمت 2 : Relational Database ها رایگان
3 آموزش کوئری (Query) گرفتن از SQL قسمت 3 : ساختار Table ها رایگان
4 آموزش کوئری (Query) گرفتن از SQL قسمت 4 : کلیدهای اصلی و فرعی رایگان
5 آموزش کوئری (Query) گرفتن از SQL قسمت 5 : رابطه بین جدول ها رایگان
6 آموزش کوئری (Query) گرفتن از SQL قسمت 7 : طراحی جدول ها رایگان
7 آموزش کوئری (Query) گرفتن از SQL قسمت 7 : طراحی ساده یک DB رایگان
8 آموزش کوئری (Query) گرفتن از SQL قسمت 8 : Normalization رایگان
9 آموزش کوئری (Query) گرفتن از SQL قسمت 9 : دستورات اولیه SQL رایگان
10 آموزش کوئری (Query) گرفتن از SQL قسمت 10 : محیط Management Studio رایگان
11 آموزش کوئری (Query) گرفتن از SQL قسمت 11 : اتصال به Database رایگان
12 آموزش کوئری (Query) گرفتن از SQL قسمت 12 : ساختار دستور SELECT رایگان
زمان و قیمت کل 0″ 0
0 نظر

هیچ نظری ارسال نشده است! اولین نظر برای این مطلب را شما ارسال کنید...

نظر شما
برای ارسال نظر باید وارد شوید.
از سرتاسر توسینسو
تنظیمات حریم خصوصی
تائید صرفنظر
×

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