نرمال سازی

[darya_22222]

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

[Mohammad_Mnt]

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

[Microsoft.net]

اگر در سیستم شما شخصی وجود داره که کد ملی و نام و مشخصات داشته باشه ولی سربازی نرفته باشه (یعنی فیلدهای نظام وظیفه Null باشه) بهتره اونو بشکنی به 2تا تیبل که یه رابطه یک به یک با هم دارند در غیر این صورت همین 1 تیبل کفایت می کنه در واقع با این کارت از اتلاف بیخودی فضا جلوگیری کردی

[AminSobati]

وجود این چند Null معدود هم مشکلی ایجاد نمیکنه که به خاطر اون مجبور بشیم یک Join رو به Queryهای خودمون تحمیل کنیم.

[Microsoft.net]

وجود این چند Null معدود هم مشکلی ایجاد نمیکنه که به خاطر اون مجبور بشیم یک Join رو به Queryهای خودمون تحمیل کنیم.

چون بحث نرمال سازی مطرح هست این سوال به وجود میاد که برای n صد هزار رکورد احتمالی چرا باید 4-5 (و یا 10-20-30 فیلد احتمالی در آینده) به صورت null همیشه تو table وجود داشته باشند ؟! اگه ما این رابطه رو به 2 تا table که باهم رابطه 1-1 دارند بشکنیم چون Join ما روی PK اتفاق می افته پس با کاهش سرعت آنچنانی روبرو نیستیم در ثانی زمانی که رکورد ایجاد میشه مطمین هستیم که اطلاعات نیاز بوده در ثالث اگه با یک آینده نگری احتمال گسترش بانک رو در نظر بگیریم می بینیم که اگه از همین الان استاندارد سازی لازم رو اعمال کنیم در آینده کمتر با مشکل مواجه خواهیم شد

در ضمن آقای Zachman روش معروفی رو دارند که به EUP معروفه Enterprise Unified Processing که در اون روشی رو برای طراحی دیتابیس پیشنهاد کردند که به اسم روش شبکه ای معروف هست در واقع در اون روش طراح برای هر قسمت از برنامش یه Table اصلی داره که به صورت هسته عمل میکنه و table های دیگه به صورت رابطه های 1-1 و 1-n به اون به صورت Node متصلند در واقع در اون روش 2 تا table اگه از طریق هسته به هم مرتبط باشند نباید با هم به صورت مستقیم مرتبط باشند . یعنی ما هر قسمت رو به صورت یک گروه که یک هسته مرکزی داره و جوری که از طریق اون هسته میشه به همه اطلاعات اون گروه دسترسی داشت طراحی میکنیم در این روش ارتباط بین گروههای مختلف فقط از طریق هسته ها برقرار میشه از مزایای این روش اینه که طراحی به صورت مستقل برای هر قسمت امکان پذیر بوده و خطرات ناشی از گسترش بانک و تغییرات اون بسیار کاهش پیدا میکنه

[darya_22222]

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

[Microsoft.net]

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

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

[AminSobati]

قوائد نرمال سازی دستورالعملی برای خارج کردن فیلدهای Null با این منطق ارائه نمیکنند. اتفاقا اگر بحث چند صد هزار رکورد هست، این سوال مطرحه که چرا باید برای بازیابی این حجم اطلاعات ، فرضا برای یک گزارش جامع، تعداد زیادی رکورد در طی Join با هم دیگه Match بشن؟! حتی اگر این Join روی دو تا PK انجام بشه!
وانگهی، وقتی پای به مرحله عمل میگذاریم، بسیاری از قوانین کلاسیک فدای اولویت های دیگه میشه. متاسفانه داشتن دو جدول به این شکل، در آینده هم بعضی امکانات رو از شما سلب میکنه مثل داشتن Indexed View برای افزایش Performance.