نرمال سازی پایگاه داده

[Mohammad_chz]

به نام خدا

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

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

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

[Mohammad_chz]

مقدمه:
نرمال سازی داده ها (Data Normalization) در حقیقت روند پالایش ساختار پایگاه داده به منظور افزایش سرعت دسترسی به داده ها و یکپارچگی آن هاست. (معمولا روش های افزایش سرعت باعث کاهش یکپارچگی داده ها می شوند و برعکس)

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

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

نرمال سازی شامل 5 قاعده کلی بهشرح زیر است که در پست های بعدی سعی می کنیم با طرح چند مثال به بررسی آنها بپردازیم.

1- حذف گروه های تکراری
2- جذف داده های موازی (پراکنده)
3- حذف ستونهایی که به کلید اولیه وابسته نیستند
4- ایزوله کردن روابط چند گانه مستقل
5- ایزوله کردن روابط چندگانه مرتبط

[Zero Defect]

سلام دوست من

ضمن تشكر از شما به خاطر درج و آغاز نشر اين مبحث مفيد ، لطفا در صورت امكان بخش زير رو تا حد امكان بازكنيد ، يك مقداري نياز به توضيح داره

جدول های سریع دارای تعداد کمی ایندکس هستند و در عوض هر رکورد می تواند دارای ستون های تکراری باشد

موفق باشيد

[Rasool-GH]

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

[Abbas Amiri]

با سلام وتشکر ازایجاد مبحث نرمال سازی پایگاه داده. ازآنجا که اگر خشت اول را کج بگذاریم کارسخت خواهد شد، بنده هم به سهم خود والبته به نقل ار دیگران چند خطی را می نگارم.
در ذیل مثالی از یکی از کتب مربوط SqlServer را بدون دخل و تصرف می آورم ، بدلیل اینکه بیشتر افراد با مثال راحت تر ارتیاط برقرار میکنند:
اگر شما می خواهیدپایگاه داده ای را طراحی کنید که قرار است اطلاعات مربوط به مشتریان ، سفارشات مشتری ، محصولات و محصولات سفارش داده شده رانگهداری کند، فرایند ایجاد طرح کلی جدولها بسیار سرراست است :
مشتریان ما دارای نام ، نام خانوادگی و آدرس هستندبنا براین مااکنون یک جدول با سه ستون داریم(به غیر از CustomerID) ، اما اگر می خواهید از آدرس جهت ارسال سفارش به مشتری استفاده کنید، نیازخواهید داشت که آدرس را به اجزای کوچکتری مانند کدپستی ، استان ، شهروخیابان تقسیم کنید.
اگر اجازه داشته باشیدکه هر مشتری تنها یک آدرس داشته باشد ، اطلاعات آدرس در جدول Customers قرارخواهندگرفت .اما اگر نیازدارید چندین آدرس را برای هر مشتری نگهداری کنید ، اکنون نیاز داریدکه جدول دومی بنام CustomerAddress را به پایگاه داده اضافه کنید.
اگر قرار بود هرمشتری تنها یک سفارش راصورت دهد، اطلاعات مربوط به سفارش درجدول Customer نگهداری میشد.اما اگر هر مشتری مجازباشد بیش ازیک سفارش داشته باشد، باید سفارش ها در یک جدول دیگر به نام Orders نگهداری شود. اگر هر سفارش شامل یک قلم کالا باشد، می توانید اطلاعات مربوط به آن را درجدول Orders نگهداری کنید، اما اگر قرارباشدمشتری بتواند درهرسفارش خود بیش ازیک کالا سفارش دهدبایدجزئیات سفارشات را درجدول دیگری که احتمالا OrderDetails نام خواهد داشت نگهداری نمایید .
می توانید این منطق رادرمورد تمام داده هایی که قراراست درپایگاه داده ذخیره شود ، به کارببرید. در اینصورت درنهایت پایگاه داده ای را طراحی کرده ایدکه از یک اصل ساده پیروی می کند:
"هرچیزی را درجای خودش قرار دهید"

ماخذ : کتاب آموزش گام به گام SQQL Servr دیباگرا ن تهران

[aromega65]

به نام خدا

(البته اگه بحث امنیت رو کنار بذاریم انصافا Access کارها رو خیلی راحت میکنه)

سلام میشه بگید کجای اکسس امنیتش ضعیفه؟؟؟؟؟؟؟؟!!!!!!!!

[Mohammad_chz]

سلام به همه دوستان

ممنون از نظرات سازنده شما.

ضمن تشكر از شما به خاطر درج و آغاز نشر اين مبحث مفيد ، لطفا در صورت امكان بخش زير رو تا حد امكان بازكنيد ، يك مقداري نياز به توضيح داره

جدول های سریع دارای تعداد کمی ایندکس هستند و در عوض هر رکورد می تواند دارای ستون های تکراری باشد


موفق باشيد

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

امکانش هست که کاربردها و معایب کلید اولیه رو توضیح بدین

کاربرد کلید اولیه برای حفظ یکپارچگی و برقراری ارتباط با سایر جداول هست که حتما توضیح داده میشه ولی معایبش!.... به نظر من هیچ عیبی بر وجود کلید اولیه مترتب نیست تا نظر دوستان چی باشه.

سلام میشه بگید کجای اکسس امنیتش ضعیفه؟؟؟؟؟؟؟؟!!!!!!!!

اما در بحث امنیت اگه از امکانات و توابع درونی اکسس استفاده کنیم بازم باید بگم انصافا کارها خیلی راحت میشه با احداقل کد می تونید فرم های بسیار زیبا و کارآمد بسازید. ولی اگه بخواهید راه های دسترسی غیر مجاز کاربر رو به داده ها مسدود کنید باید مقدار زیادی کد تولید کنید چون توابع داخلی اکسس زیاد نیست و مجبورید مقدار زیادی تابع User Define بسازید که به نوبه خوش بازد کد بیشتری بایدتولید کنید یا از توابع طراحی شده دیگران استفاده کنید. خلاصه اینکه شخصا خودم بعد از بررسی تمام مقالات امنیتی موجود در سایت تصمیم گرفتم که با همون #C برنامه نهایی رو بسازم. چون اگه قرار باشه این همه کد بنویسم اونو به #C منتقل می کنم و از امکانات فوق العاده VS استفاده می کنم. البته شاید دلیلش عدم آشنایی کامل من با Access باشد (اولش گفتم من حرفه ای اکسس نیستم)

از دوست خوبمون آقای امیری هم بابت مطلب بسیار مفیدشون تشکر میکنم

[Mohammad_chz]

1- حذف گروه های تکراری:

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

Befor.jpg

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

اولین مرحله:
فیلدهای مهارت شغلی کارکنان تکراری است (SkillCode1,........,SkillName1,........) اگر کارمندی بیش از 3 مهارت داشت مهارت چهارم را چه کار کنیم؟ ضمنا اکثر کارمندان فقط یک یا 2 مهارت شغلی دارند. چطور میشه راحت لیست تمام کارکنانی که دارای مهارت خاص هستند رو از این جدول استخراج کرد؟

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

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

NF1.jpg

حالا اگر کارمندی دارای چندین مهرات باشه به تعداد مهارت های وی رکورد در جدول Skills وجود داره. در همه رکوردهای جدول Skills فیلد EmpID باید حاوی یک مقدار مجاز باشه و پایگاه داده ار قرار گرفتن مقادیر غیر مجاز در این ستون جلوگیری میکنه.

توجه: جهت تعریف کلید اولیه اگر امکان استفاده از فیلد عددی هست نباید از فیلد رشته ای استفاده کرد.

دوستان من نوشتنم زیاد خوب نیست اگه احساس میکنید توضیحات زیاد یا کمه لطفا بگید منم ممنون میشم.
مبحث بعدی: حذف داده های موازی (پراکنده)

[Zero Defect]

با سلام

از خوش اقباليست كه بنده هم همچون شما دوست گرامي مسن هستم .

دوستان محترمی که سابقا با فاکس پرو یا سایر پایگاه های داده ای که ....

خوب پس با اين اوصاف و با توجه به اينكه موضوع با فاكس پرو مرتبط شد پس

جدول های سریع دارای تعداد کمی ایندکس هستند و در عوض هر رکورد می تواند دارای ستون های تکراری باشد

اين جمله بدين شكل كه مرتبط نشون داده شدند اشتباه هستش

تعدد ستونها با موضوع نرمال سازي در تقابل كامل قرار داره

ايندكس گذاري ممكنه به دسترسي سريعتر به اطلاعات منجر بشه ( حالتهاي مختلف با توجه به نوع تنظيم امكان پذيره ، حالتهايي از افزايش سرعت تا عدم تاثير )

بر همين اساس ايندكس گذاري منجر به تاثير در سرعت جدول نخواهد شد ، چرا كه پارامتري به عنوان سرعت جدول نداريم ، هر آنچه كه هست سرعت دسترسي به اطلاعاته
توضيح بيشتر در صورت نياز ارائه خواهد شد

در خصوص امنيت اكسس توجيهي كه فرموديد هم درسته و هم غلط ، در اين خصوص قبلآ مطالب چندي درج شد ، اونها رو مطالعه بفرماييد ( با نامهاي كاربري nabeel - Zerodefect )

دوست من تفاوت آشكاري وجود داره بين يك IDE و Database

خلاصه اینکه شخصا خودم بعد از بررسی تمام مقالات امنیتی موجود در سایت تصمیم گرفتم که با همون #C برنامه نهایی رو بسازم. چون اگه قرار باشه این همه کد بنویسم اونو به #C منتقل می کنم و از امکانات فوق العاده VS استفاده می کنم

نقص در محيط IDE نهفته نيست در محل ذخيره سازي هستش

در مجموع اميدوارم نقائص وارد شده مورد كند و كاو قرار بگيره تا مقاله در بهترين حالت خودش و به گونه اي كاربردي و منطبق بر واقعيات موجود در ديتابيسهاي جديد مطرح بشه تا به مطالب خدشه اي وارد نشه

اون جمله اي كه بنده ايراد وارد كردم چون در خشتهاي اوليه مبحثتون قرار داره در صورتي كه به صورتي غير شفاف تبيين بشه منجر به دو انگاري در مطالب خواهد شد چرا كه ذكر مطلبي كه بر خلاف جهت عنوان اصلي موضوع هست براي كاربران تازه كار ايجاد شبه خواهد كرد

در مجموع مجددا از شما تشكر ميكنم در جايي كه كمتر كسي حوصله درج اينگونه مطالبي رو داره وجود شما براي اين تالار نعمتي خواهد بود

با تشكر از زحمات شما

[Rasool-GH]

سلام
خدمت همه اساتيد خسته نباشيد عرض ميكنم . خدا قوت
منظور بنده از مطرح كردن بحث كليد اوليه اين بود كه به طور مثال يك فيلد كه به صورت ايندكس و بدون قابليت دريافت داده تكراري تعريف شده چه تفاوتي با كليد اوليه داره ؟ (بسيار مشابه هم هستن)

[Mohammad_chz]

تعدد ستونها با موضوع نرمال سازي در تقابل كامل قرار داره

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

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

دوست من تفاوت آشكاري وجود داره بين يك IDE و Database

بازم ببخشید نقص از گفتار منه. صحبت شما کاملا درسته ولی زمانی که شما تمام لایه های برنامه از جمله PL,BLL,DAL را در اکسس تهیه میکنید خوب مسلما نواقص موجود بیشتر حس میشه.
ضمنا من تمام مقالات ذکر شده را خوندم. به دلایلی در پروژه جدیدم بعضی از مقتضیات پروژه با امکانات امنیتی اکسس در تقابل بود. ولی من باب امنیت ذکر کنم با مطالعه مقالات سایت من جمله همون مقالاتی که حضرتعالی ذکر کردید به نتایج خیلی خوبی رسیدم ولی برای حفظ امنیت داده کدهای زیادی نیاز بود (در صورت لزوم قابل بحث هست) که با وجود تکنولوژی های جدید محیط IDE بهتره کد نویسی ها در این محیط انجام بشه.
یه موضوع دیگه ذکر کنم که با استفاده از مقالات بسیار آموزنده موجود شخصا برنامه ای در اکسس طراحی کردم که عبور از لایه های امنیتی اون بسته به توان و مهارت اشخاص حداقل چندین ماه طول میکشه که اینم مدیون همین سایت و اعضای محترم هستم چون واقعا قبل از این اطلاعات من در مورد اکسس در حد صفر بود.

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

[Zero Defect]

سلام دوست من

با توجه به اينكه فرموديد در هر دو نقيصه مشكل به نحوه نگارش برميگشته پس موضوع منفيه

يه مقدار با هم در خصوص ايندكس مشكل داريم ( تعدد رو عرض نميكنم بلكه نحوه تاثير گذاري رو مد نظرمه ) در اون رابطه زياد وارد موضوع در اينجا نميشم

موضوع قبلا در اينجا مطرح شده بود

در خصوص مبحث IDE هم اگر خواستيد در يك تاپيك مجزا به گفتگو مينشينيم

در مجموع از مطالبتون سپاسگزارم و در انتظار مطالب آتي شما خواهيم بود

Rasool-GH دوست گرامي

پاسخ سئوال شما هم در همون لينك وجود داره

موفق باشيد

[Mohammad_chz]

یکی شکسته خواند یکی نشسته خواند---------------هر کس به قدر فهمش از این نوشته داند

دوست عزیز :Zero Defect: خوشبختانه شما از نثر بسیار زیبا و روانی برخودار هستید و این مایه خوشحالی خود من هم هست چون همه می تونن از نوشته های شما استفاده کنند. در کل تفاوت زیادی در افکار ما نیست ولی من خوب نمی تونم بیان کنم. حکایت نان و انگور مولانا شد همه یه چیز میگیم ولی به زبان خودمون. لینک موجود رو مشاهده کردم مطالبی که موجود بود شباهت زیادی به همون رفرنسی داشت که من عرض کردم.

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

[Rasool-GH]

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

مفهوم Index و تاثیر آن بر روی برنامه
سلام

مطلب رو با مثال زیر شروع میکنم :

مطمئناً همه ما دفتر تلفنهایی که در گوشه صفحه اونها تقسم بندی ( در اینجا الفبایی ) وجود داره رو دیدیم .

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

Index الزاماً عدم پیمایش کل رکوردها رو به همراه نداره . به سناریوهای زیر توجه کنید :

رکورد مورد بحث در آخرین ردیف قرار داره ( که البته برای وقوع همیشگی این مورد دیگه باید دیوار خیلی کوتاهی داشته باشید )

ولی دومین امر تنظیمات دو گانه Index هستش . در حالتی که مجوز تکرار داده شده باشه ( Duplicates OK ) پروسه پیمایش همچنان تا آخرین رکورد ادامه پیدا میکنه در واقع شما با انتخاب حالت No Duplicates هست که به اکسس این اطمینان خاطر رو میدید که به اولین رکورد مورد نظر که رسیدی دیگه به دنبال رکورد دیگه ای نگرد حال این رکورد میتونه :

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

اعمالی که باعث بی تاثیری و ناکارمدی Index میشه تعدد Index های یک جدول و اینکه Index بر روی چه چیزی گذاشته شده هستش . ( به طور مثال از دید من Index گذاری مبلغ منطقی نیست )

با هم به مثال دفتر تلفن رجوع میکنم :

تقسیم بندی های دفتر تلفن تا وقتی ارزشمنده که گروههای انتخابی نه خیلی بزرگ و نه خیلی کوچیک باشن به طور مثال در یک دفتر تلفن استاندارد حرف الف در یک گروه , حرف ب در یک گروه و ... قرار میگیرن حالا تصور کنید که تقسم بندی این دفتر تلفن رو خیلی خرد کنیم و برای نبیل پیروزمهر یک صفحه و برای X و Y هم هر یک , یک صفحه رو در نظر بگیریم . در این حالت Index گذاری به عنوان یک ضد سیستم عمل میکنه و نبودش بهتر از بودنشه .

امری که منع میشه تعدد فیلدهای شاخص گذاری شده هستش .

به نظرم Index گذاری باعث کاهش سرعت در دیتا بیسی با تعداد رکورد کم نمیشه .

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

پی نوشت :

در کنار مشخصه Index مولفه دیگه ای وجود داره با نام Primary Key

این دو مشخصه دارای فصل مشترکی زیادی هستند و لیکن تفاوتهای اختصاصی زیر رو با هم دارند

Primary Key اشاره به يك موجوديت منحصر به فرد داره ، مقدار Null‌ رو هم نمي پذيره ( در حالت ساده ، مجوز خالي بودن فيلد رو نميده )

Indexed Field عملكردي مشابه با همون Primary Key‌ داره ( در حالت No Duplicate ) با اين تفاوت كه اجازه مقدار Null‌ رو در فيلد ميده

بر همين اساس اگر قصد داريد كنترل كاملي بر روي عدم تكرار يك فيلد داشته باشيد بايد از Primary Key‌ استفاده كنيد ، چرا كه Index‌ تنها در حالتي كه مقداري در داخل فيلد وارد شده باشه بر روي عدم تكراري بودن نظارت ميكنه

معمولا از Index‌ بر روي فيلدهايي استفاده ميشه كه بيشتر مورد جستجو قرار ميگيرند

منبع : cpsd.irسایت

[Mohammad_chz]

2- داده های پراکنده را حذف کنید:

جنبه دیگر قابل توجه در مثال ما اینه که جداول دارای داده های پراکنده ریادی است.

داده هایی که در چندین جای پایگاه داده ذخیره شده باشند داده های پراکنده هستند که منجر به برو مشکلات جدی برای یکپارچگی پایگاه داده می شود.

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

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

جدول Skills قبلی را به EmpSkill تغییر نام می دهیم و جدول جدیدی به نام SkillMaster می سازیم.
حالا پایگاه شما باید چیزی شبیه زیر باشد:

NF2.jpg

[Mohammad_chz]

3- حذف ستون هایی که به کلید اولیه وابسته نیستند:

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

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

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

با تفکیک آن شکل پایگاه داده شبیه زیر خواهد شد.

NF3.jpg

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

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

[مهدی د]

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

[مهدی د]

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

[مهدی د]

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

[Mohammad_chz]

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

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

در برخی شرکتها فقط به بعضی از این فیلدها نیاز می شود و ممکن است بعضی از پرسنل هم فقط به برخی از آنها نیاز داشته باشند

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

در یک برنامه حقوق و دستمزد جدول اطلاعات پرسنلی را به دو جدول جداگانه تقسیم کردم ...

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

اگه فایلتون رو با توضیحات بذارید براتون نرمال می کنم.

[Mohammad_chz]

4- روابط چندگانه مستقل را ایزوله کنید:

هر گاه یک جدول دارای چند رابطه یک به چند باشد به این قاعده نیاز است. در مثال ما بین جداول Employees و EmpSkills یک رابطه یک به چند وجود دارد. اجازه بدید یک رابطه یک به چنددیگر بید دو جدول برقرار کنیم. فرض کنید امور اداری شرکت مفروض درخواست اضافه کردن مدارک تحصیلی کارمندان را به پایگاه داده کرده است. برای اینکار در وهله نخست می توان فیلد جدید به نام Degrees (مدرک تحصیلی) و شاید فیلدی به نام YearCompleted (سال اخد مدرک) را به جدول EmpSkill اضافه کرد. در ظاهر کار از آنجا که هر مدرکی با یک مهارت تناظر دارد به نظر می آید این روش مناسب باشد. اما در عمل چنین نیست چون در خیلی از موارد شغل یک کارمند ربطی به مدرک تحصیلی وی ندارد پس مدرک تحصیلی با مهارت های شغلی نیز تناظر ندارند. به عنوان راه حل می توان یک جدول جدید ایجاد کرد و اطلاعات تازه را در آن قرار داد.

قاعده چهارم نرمال سازی می گوید: هیچ جدولی نباید دارای دو (یا چند) رابطه یک به چند (یا چند به چند) مستقل (که مستقینا به هم مربوط نیستند) باشد.

با اعمال قاعده فوق شکل پایگاه داده شبیه زیر خواهد شد.

NF4.jpg

[مهدی د]

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

[Mohammad_chz]

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

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

قاعده پنجم نرمال سازی می گوید: روابط چند گانه مرتبط درون هر پایگاه داده باید از هم ایزوله شوند. به عبارت دیگر اگر پایگاه داده ای دارای چندید رابطه پیچیده است باید هر کدام از رابطه ها در جدول مستقل قرار گیرد.

لیست زیر روابطی است که در مثال ما وجود دارد:

• هر استاد می تواند چندین مهارت تدریس کند
• هر مهارت می تواند توسط چندین استاد تدریس گردد
• هر اداره ممکن است دارای چندین مهارت قابل تدریس باشد
• هر اداره ممکن است مایل باشد با استاد خاصی همکاری کند

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

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

NF5.jpg

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

[Rasool-GH]

یه سوال دارم چرا با وجود جدول SkillMaster که فیلد Name رو داره هنوز فیلد SkillName در جدول EmpSkill وجود داره . من اشتباه میکنم یا سهوا پیش اومده ؟

[abdoreza57]

با سلام و خسته نباشید


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

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


اساتید و دوستان محترمی که راه حل مناسب و راهمکار مناسب را برای حل این مشکل می دانند از راهمایی خود ما را بی نصیب نکنند

[Mohammad_chz]

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

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

[Mohammad_chz]

به نام خدا

دوست عزیز Rasool-GH قبل از هر چیز بابت دیر جواب دادنم معذرت میخوام. متوجه پست شما نشدم.

یه سوال دارم چرا با وجود جدول SkillMaster که فیلد Name رو داره هنوز فیلد SkillName در جدول EmpSkill وجود داره . من اشتباه میکنم یا سهوا پیش اومده ؟

حق با شماست اشتباه شده که البته سهوی بوده. در جدول EmpSkill نباید فیلد SkillName قرار می گرفت. از تذکر به جای شما واقعا متشکرم. این نشانه دقت نظر زیاد شماست.

[Mohammad_chz]

به نام خدا
دوست عزیز مهدی د فرموده بودید:

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

با عرض پوزش از اینکه دیر جواب دادم. مدتیه به علت مشغله زیاد کمتر به سایت سر میزنم. امیداورم پوزش بنده رو بپذیرید. ضمنا باید ازتون به خاطر تاپیک ارزشمندی که ایجاد کردید تشکر کنم. مطالب بسیار جالب و طرح های زیبایی از نمونه کار دوستان رو دیدم که الهام بخش هستند (انشاا... برای پروژه های بعدی).

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

امیدوارم تونسته باشم جواب سئوال شماره بدم.

[abdoreza57]

سلام

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


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

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

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

2) با توجه با تغییرات خوبی که تو مجموعه جداول ایجاد نمودید و اینکه وضعیت سفارش را ایجاد نمودید در صورت کنسل شدن سفارش
رکورد می بایست حذف شود و یا توسط آن فیلتر شود ؟

[Mohammad_chz]

به نام خدا

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

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

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

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

در صورت کنسل شدن سفارش
رکورد می بایست حذف شود و یا توسط آن فیلتر شود ؟

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

[abdoreza57]

سلام

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

تو نمونه قبلی خودم جهت مراجعات بعدی مشتری از عمل Duplicate Record که کل رکورد را کپی کرده و با فیلد
شماره موبایل دفعات مراجعه مشتری مشخص و اندازه ها با فیلد شماره سفارش فیلتر شده و قابل دسترسی بود
ضمن قبول نقص موجود در این زمینه

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

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



3) مهمتر از همه در زمان صدور فاکتور برای مشتری این روابط را چگونه برقرار سازم چون اندازه ها نزد ما و فاکتور قیمت ها نزد مشتری میماند ؟

[abdoreza57]

با سلام خدمت تمام دوستان خوبم

در خصوص نرمال سازي برنامه اي كه مد نظرم بود همانطور كه دوست گراميم راهنماييهاي خوبي نمودند و زحمت اين
مهم را نيز كشيدند بر آن شدم اين رويه را انجام دهم و كلا ساختار بانك قبلي را مطابق نظر و روش صحيحي كه
فرمودند تغيير دهم ولي از آنجا كه تمام مسايل مرتبط را مي بايست مد نظر داشت تا پس از پايان كار شاهد عدم
كارايي سيستم نباشيم معروض ميدارم :


1) هر فاكتور بنام يك مشتري است (رابطه يك به چند )

2) در هر فاكتور مشتري داراي يك يا چند نوع كالاست (كت و شلوار يا ...) كه مختص اين فاكتور مي باشد
با اين حال كه اين كالاها مختص همين مشتري مي باشد (رابطه چند به چند ؟)

3) اطلاعات كالاهاي مشتريان بنام خودشان بايگاني و هنگام صدور فاكتور قابل دسترسي است
بنابراين در هر فاكتور با انتخاب مشتري كالاهاي مربوط به او نمايش داده ميشود تا بتوان در صورت نياز از آن استفاده نمود و يا يك ركورد جديد براي كالاي مد نظر مشتري ايجاد نمود .



با توجه به مسايل گفته شده به نظر ميرسد راه سخت و دشواري باشد كه پس از چند هفته نتونستم راه مناسبي براي اين مسئله بيابم البته اين به نداشتن معلوماتم و پيچيدگي روابط موجود در اين بانك ميباشد

اگر دوستان گرامي لطف كنند و اين مسئله را تا به سرانجام رسيدن آن ياري كنند ممنون خواهم بود


فايل پيوست قبل را با توجه به خواسته هام و اصلاح روابط موجود به جايي رسونده ام كه ايرادات آن ميبايست گرفته شود از تمام دوستان درخواست همكاري دارم

[msabbaghi]

این هم نمونه خوبی برای شزوع هستش
http://fyek.ir/learning/%D9%BE%D8%A7...%AF%D9%87.html

[espstn]

سلام آقايون من يه نرم افزار نرمال سازي مي خوام برا پروژه در پايگاه دادهام كه تا فردا يعني 13/3/92 مي خوامش اگر كسي مي تونه بهم كمك كنه وبهم اين نرم افزار رو بده خيلي ممنون مي شم.
درضمن شرمنده فقط اين سه تا نباشه چون استادم گفته قبول نمي كنه : 1- database normalizer
2- prof.ing software
3- db normalizer
شرمنده هركي داره اگر مي شه زودتر بزاره برام ممنون ميشم.

[Rasool-GH]

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

حالا برای ثبت یک دستگاه با 2 ورودی و 10 خروجی نیاز به چند جدول مجزا داریم ؟

جدول مشخصات دستگاه شامل (کد دستگاه - نام دستگاه - ادرس دستگاه)
جدول مشخصات کابلها شامل (کد کابل - سایز کابل)
جدول مشخصات جنس کابلها شامل (کد جنس - جنس کابل )

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

جدول کابلهای ورودی شامل (کد دستگاه - سایز کابل - جنس کابل)
جدول کابلهای خروجی شامل (کد دستگاه - سایز کابل - جنس کابل)

یا یک جدول به صورت

جدول کابلها شامل (کد دستگاه - نوع کابل (ورودی یا خروجی) - سایز کابل - جنس کابل)

ممنون از توجه دوستان

[Rasool-GH]

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

[Rasool-GH]

یک مورد جدید هم برخورد کردم که خیلی دستمو بسته . در محیط ریلیشن به یک جدول بیش از 26 ارتباط رو اجازه نمیده برقرار کرد . ایا راه حل خاصی داره یا باید 2 نسخه از جدول رو وارد محیط ریلیشن کرد

[Rasool-GH]

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

[Rasool-GH]

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

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

توضیحی که لازم به نظر میرسه اینه که گزارش 1 حاصل از یک پایگاه رکورد گراست و گزارش 2 نتیجه یک پایگاه نرمال شده است

در نمونه زیر دو گزارش رو اجرا کنید و نام ناصر رو گزارش بگیرید

[alirezabahrami]

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

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

در نمونه زیر دو گزارش رو اجرا کنید و نام ناصر رو گزارش بگیرید

سلام
در کوئری مربوطه روابط جداول را اصلاح کن !
موفق باشید