PDA

View Full Version : آموزش: نرمال سازی پایگاه داده



Mohammad_chz
دوشنبه 05 دی 1390, 12:40 بعد از ظهر
به نام خدا

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

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

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

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

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

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

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

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

Zero Defect
دوشنبه 05 دی 1390, 13:21 بعد از ظهر
سلام دوست من

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


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

موفق باشيد

Rasool-GH
دوشنبه 05 دی 1390, 15:34 بعد از ظهر
بحث خوبیه . اگه لطف کنید و تا یه جایی که به درد اکثریت بخوره ادامه بدین خیلی خوبه
امکانش هست که کاربردها و معایب کلید اولیه رو توضیح بدین

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

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

aromega65
دوشنبه 05 دی 1390, 21:06 بعد از ظهر
به نام خدا

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


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

Mohammad_chz
سه شنبه 06 دی 1390, 09:06 قبل از ظهر
سلام به همه دوستان

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


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

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


موفق باشيد

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



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

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


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

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

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

Mohammad_chz
سه شنبه 06 دی 1390, 09:22 قبل از ظهر
1- حذف گروه های تکراری:

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

79767



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

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

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

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


79768




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

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

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

Zero Defect
سه شنبه 06 دی 1390, 10:15 قبل از ظهر
با سلام

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


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

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


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

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

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

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

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

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

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



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

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

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

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

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

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

Rasool-GH
سه شنبه 06 دی 1390, 10:35 قبل از ظهر
سلام
خدمت همه اساتيد خسته نباشيد عرض ميكنم . خدا قوت
منظور بنده از مطرح كردن بحث كليد اوليه اين بود كه به طور مثال يك فيلد كه به صورت ايندكس و بدون قابليت دريافت داده تكراري تعريف شده چه تفاوتي با كليد اوليه داره ؟ (بسيار مشابه هم هستن)

Mohammad_chz
سه شنبه 06 دی 1390, 10:49 قبل از ظهر
تعدد ستونها با موضوع نرمال سازي در تقابل كامل قرار داره

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

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


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

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

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

Zero Defect
سه شنبه 06 دی 1390, 11:31 قبل از ظهر
سلام دوست من

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

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

موضوع قبلا در اينجا مطرح شده بود (http://cpsd.ir/forum/showthread.php?tid=180&pid=254#pid254)

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

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

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

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

موفق باشيد

Mohammad_chz
سه شنبه 06 دی 1390, 11:51 قبل از ظهر
یکی شکسته خواند یکی نشسته خواند---------------هر کس به قدر فهمش از این نوشته داند

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

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

Rasool-GH
سه شنبه 06 دی 1390, 22:44 بعد از ظهر
ممنون بابت راهنمایی
فکر میکنم اگه مطلب رو با ذکر منبع به اینجا انتقال بدیم بهتر باشه . چون ممکنه بعدها این مطلب پاک بشه و از دسترس سایرین خارج بشه


مفهوم 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سایت (http://cpsd.ir/forum/showthread.php?tid=180&pid=254#pid254)

Mohammad_chz
چهارشنبه 07 دی 1390, 08:59 قبل از ظهر
2- داده های پراکنده را حذف کنید:

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

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

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

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

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


79810

http://barnamenevis.org/images/misc/pencil.png

Mohammad_chz
چهارشنبه 07 دی 1390, 09:12 قبل از ظهر
3- حذف ستون هایی که به کلید اولیه وابسته نیستند:

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

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

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

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

79812

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

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

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

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

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

Mohammad_chz
جمعه 09 دی 1390, 16:18 بعد از ظهر
در چه شرایطی برنامه نویس مجبور است قواعد نرمال سازی را نادیده بگیرد و قواعد نرمال سازی در چه شرایطی کاربرد ندارد؟

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



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

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



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

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

Mohammad_chz
جمعه 09 دی 1390, 16:34 بعد از ظهر
4- روابط چندگانه مستقل را ایزوله کنید:

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

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

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

79902

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

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

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

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

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


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

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

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

79904

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

Rasool-GH
سه شنبه 13 دی 1390, 21:43 بعد از ظهر
یه سوال دارم چرا با وجود جدول SkillMaster که فیلد Name رو داره هنوز فیلد SkillName در جدول EmpSkill وجود داره . من اشتباه میکنم یا سهوا پیش اومده ؟

abdoreza57
پنجشنبه 22 دی 1390, 14:03 بعد از ظهر
با سلام و خسته نباشید


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

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


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

Mohammad_chz
پنجشنبه 22 دی 1390, 17:10 بعد از ظهر
به نام خدا
سلام دوست عزیز
بانک فعلی شما دارای نواقصی بود که خودتون به بعضی هاش اشاره کرده بودید. چند موردشو من میگم تا مطلب رون تر بشه. فرضا اگه یهمشتری هم کت و هم شلوار و هم پیراهن سفارش مبده ولی جدا جدا تحویل بگیره چطوری تاریخ تحویل بقیه مشخص میشه یا چطوری وضعیت تحویل مشخص میشه. یا اگه یه مشتری اقلامی رو به فاصله چند روز ولی جدا گانه سفارش بده چطوری ثبت میشه.
تو این بانک نمی تونید بهراحتی از همه سفارش های یه مشتری گزارش تهیه کنید.

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

Mohammad_chz
یکشنبه 25 دی 1390, 11:11 قبل از ظهر
به نام خدا

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


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

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

Mohammad_chz
یکشنبه 25 دی 1390, 11:45 قبل از ظهر
به نام خدا
دوست عزیز مهدی د فرموده بودید:


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

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

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

abdoreza57
سه شنبه 27 دی 1390, 16:46 بعد از ظهر
سلام

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


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

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

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

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

Mohammad_chz
سه شنبه 27 دی 1390, 17:19 بعد از ظهر
به نام خدا

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

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


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

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


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

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

abdoreza57
سه شنبه 27 دی 1390, 21:16 بعد از ظهر
سلام

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

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



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

abdoreza57
شنبه 15 بهمن 1390, 09:34 قبل از ظهر
با سلام خدمت تمام دوستان خوبم :خجالت:

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


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

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

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



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

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


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

msabbaghi
جمعه 18 اسفند 1391, 08:05 قبل از ظهر
این هم نمونه خوبی برای شزوع هستش
http://fyek.ir/learning/%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87-sql-server-2012/%D8%B7%D8%B1%D8%A7%D8%AD%DB%8C-%D9%88-%D9%BE%DB%8C%D8%A7%D8%AF%D9%87-%D8%B3%D8%A7%D8%B2%DB%8C-%D8%A8%D8%A7%D9%86%DA%A9-%D8%A7%D8%B7%D9%84%D8%A7%D8%B9%D8%A7%D8%AA%DB%8C/87-%D9%86%D8%B1%D9%85%D8%A7%D9%84-%D8%B3%D8%A7%D8%B2%DB%8C-%D9%BE%D8%A7%DB%8C%DA%AF%D8%A7%D9%87-%D8%AF%D8%A7%D8%AF%D9%87.html

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

Rasool-GH
شنبه 22 شهریور 1393, 12:04 بعد از ظهر
سلام خدمت همه دوستان
به نظر اساتید برای مثال زیر با شرایطی که عنوان شده چند جدول لازمه
یک دستگاه داریم که 2 نوع کابل به اون متصل هست . ورودی و خروجی ( امکان داره تعداد هر کدوم یکی یا بیشتر باشه ) . این کابلها در سایزهای مختلف و جنسهای مختلف هستند .

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

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

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

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

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

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

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

Rasool-GH
یکشنبه 23 شهریور 1393, 22:36 بعد از ظهر
ضمنا یک مورد دیگه اینکه ایا در برقراری ریلیشن بین جداول ایا تعداد ارتباط ها به سرعت اجرا برنامه مربوطه .
اگه ارتباط ها خیلی زیاد باشه کندی در اجرا محسوس خواهد بود یا نه

Rasool-GH
دوشنبه 24 شهریور 1393, 10:47 قبل از ظهر
یک مورد جدید هم برخورد کردم که خیلی دستمو بسته . در محیط ریلیشن به یک جدول بیش از 26 ارتباط رو اجازه نمیده برقرار کرد . ایا راه حل خاصی داره یا باید 2 نسخه از جدول رو وارد محیط ریلیشن کرد

Rasool-GH
سه شنبه 10 شهریور 1394, 20:15 بعد از ظهر
سلام خدمت دوستان عزیز مخصوصا جناب امیری
دو درخواست دارم اول اینکه لطفا نوشته های جناب پیروزمهر رو از حالت مخفی خارج کنید .
دوم اینکه در مورد سوالی که در 3 پست قبلی مطرح کردم اگر جوابی به نظرتون میرسه بفرمایید

Rasool-GH
چهارشنبه 11 شهریور 1394, 11:32 قبل از ظهر
سلام مجدد
یکی از مواردی که در ابتدای بحث نرمال سازی مطرح شد جدا کردن جداول به تفکیک اطلاعات دسته بندی شده است ولی این اقدام به نظر بنده مشکلی رو در انتها در امر تهیه گزارش ایجاد میکند که راح حل اون رو نمیدونم .
به طور مثال

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

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

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

alirezabahrami
چهارشنبه 11 شهریور 1394, 13:26 بعد از ظهر
سلام مجدد
یکی از مواردی که در ابتدای بحث نرمال سازی مطرح شد جدا کردن جداول به تفکیک اطلاعات دسته بندی شده است ولی این اقدام به نظر بنده مشکلی رو در انتها در امر تهیه گزارش ایجاد میکند که راح حل اون رو نمیدونم .
به طور مثال

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

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

Rasool-GH
چهارشنبه 11 شهریور 1394, 14:52 بعد از ظهر
سلام و ممنون
اما در این صورت مهارت دوم فرد گزارش نمیشه

alirezabahrami
چهارشنبه 11 شهریور 1394, 21:46 بعد از ظهر
سلام و ممنون
اما در این صورت مهارت دوم فرد گزارش نمیشه
سلام
با این وجود نیاز است که ابتدا یک کپی از کوئری 1 را که مشخصات فرد را در رکورد های جداگانه و زیر هم نمایش میدهد تهیه و آن را در حالت گروه قرار بدهیم تا اطلاعات اولیه هر فرد در یک رکورد نمایش داده شود و سپس از طریق DLookUp مهارت و زمینه کاری دیگر فرد را با توجه به رکوردهای کوئری 1 استخراج و در دو ستون جداگانه با عناوین جدید درج نمائیم .

alirezabahrami
پنجشنبه 12 شهریور 1394, 10:31 قبل از ظهر
با سلام مجدد
توضیحات و نمونه پست قبل اصلاح گردید
یا علی

Rasool-GH
پنجشنبه 12 شهریور 1394, 13:10 بعد از ظهر
خیلی لطف کردین جناب بهرامی ممنون .
در این مورد هم اظهار نظر بفرمایید که ایا اصولا این راه درستی برای نرمال سازی پایگاه داده به حساب میاد یا روش باید تغییر کنه ؟

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

alirezabahrami
پنجشنبه 12 شهریور 1394, 16:19 بعد از ظهر
خیلی لطف کردین جناب بهرامی ممنون .
در این مورد هم اظهار نظر بفرمایید که ایا اصولا این راه درستی برای نرمال سازی پایگاه داده به حساب میاد یا روش باید تغییر کنه ؟

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

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

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

Rasool-GH
پنجشنبه 12 شهریور 1394, 17:40 بعد از ظهر
سلام
همین کمک شما هم بسیار راه گشا هست . در مورد کراس تب هم اگه لطف کنید و توضیح مختصری با یک نمونه بدید خیلی خوبه .
حرف شما رو قبول دارم که مشکلات به ظاهر لاینحل رو با متدهای خواصی میشه حل کرد ولی بعد برای ویرایش و توسعه به همون میزان مشکلات خواصی پیش خواهد اومد . روشها و راهکارهای روتین بهترین هستند برای استاندارد سازی و البته فراهم کردن بستر توسعه .

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

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

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

به هر صورت از لطف و توجه شما سپاسگذارم .


جناب پیروزمهر و جناب امیری لطفا بنده رو از نظرات خوبتون بی نصیب نگذارید .
ممنون

Rasool-GH
جمعه 13 شهریور 1394, 09:35 قبل از ظهر
این مطلب هم در مورد نرمال سازی و شیوه های اونه

نرمال سازی بانك های اطلاعاتی


نرمال سازی ( Normalization ) يا به تعبيری هنجار سازی فرآيندی است در رابطه با بانك های اطلاعاتی كه با دو هدف عمده زير انجام می شود :
• کاهش افزونگی اطلاعات ، به اين معنی که اطلاعات فقط در يک مكان (جدول) ذخيره و در تمام بانک با استفاده از روابط منطقی تعريف شده (RelationShip) قابل دسترسی باشد .
• حفظ يکپارچگی اطلاعات ، به اين معنی که اعمال تغييرات بر روی اطلاعات ( نظير ايجاد ، بهنگام سازی و حذف ) در يك مكان انجام و به دنبال آن آثار تغييرات در تمام بانك مشاهده گردد . برای روشن شدن مفهوم يکپارچگی بد نيست به مثال ذيل توجه نمائيد :
فرض كنيد در يك بانك اطلاعاتی دارای دو موجوديت كتاب و نويسنده باشيم . هر يك از موجوديت های فوق دارای المان های اطلاعاتی (Attribute) مختص به خود می باشند . به عنوان نمونه موجوديت "كتاب" دارای المان اطلاعاتی نام نويسنده و موجوديت "نويسنده " دارای المان های اطلاعاتی متعددی نظير نام نويسنده ، آدرس نويسنده و ... باشد . در صورتی كه در موجوديت "کتاب" يک رخداد (رکورد) ايجاد نمائيم بدون اينکه نام نويسنده آن را در موجوديت "نويسنده" ايجاد کرده باشيم ، دچار يک ناهمگونی اطلاعات خواهيم شد .
با توجه به اهداف فوق می توان گفت كه فرآيند نرمال سازی از ناهنجاری های بوجود آمده به دليل بروز تغييرات در بانك جلوگيری خواهد نمود . با اعمال فرآيند نرمال سازی ، يك بانك اطلاعاتی كارآ و مطمئن را خواهيم داشت .
فرآيند نرمال سازی ، فرم های متفاوتی دارد كه انواع متداول آن به شرح ذيل است :
• فرم اول نرمال سازی 1NF
• فرم دوم نرمال سازی 2NF
• فرم سوم نرمال سازی 3NF
• فرم بويس کد نرمال سازی BCNF
• فرم چهارم نرمال سازی 4NF
فرم اول نرمال 1NF

موجوديت و يا جدولی در فرم اول نرمال است كه تمامی المان های اطلاعاتی آن ( منظور Attribute است ) يكتا و يا اصطلاحا" atomic باشند . برای روشن شدن اين موضوع فرض كنيد دارای موجوديتی با نام "فاكتور فروش " باشيم .
134949
با مشاهده موجوديت فوق متوجه اين موضوع خواهيم شد كه المان های كالا ، تعداد كالا و قيمت واحد كالا بيش از يك مرتبه در موجوديت وجود داشته و اصطلاحا" يك گروه تكرار را تشكيل می دهند . برای اجرای مدل فيزيكی اين موجوديت ناچار خواهيم بود در طراحی جدول آرايه ای به طول ثابت ( به عنوان نمونه با ده عضو ) تعريف و در آن به ترتيب كالای 1 تا 10 را تعريف نمائيم .
مشکل : طراحی فوق ما را با دو مشکل عمده روبرو خواهد ساخت : اول اين كه کارائی بانک اطلاعاتی پائين خواهد آمد (اگر در آينده تعداد کالاهای فاکتور فروش بيش از 10 کالا باشد ، آنگاه مجبور خواهيم بود طراحی جدول مربوطه و متعاقب آن نرم افزارهائی که از آن استفاده می كنند را تغيير دهيم ) و مشکل دوم اين كه بسياري از فاکتورها لزوما" دارای 10 کالا نيستند و بنابراين محتوی بسياری از فيلدها در جدول فوق خالی (داراي ارزش Null) خواهد ماند و حجم زيادی از فضای ديسک هدر خواهد رفت .
راه حل : برای حل اين مشکل کافی است تمامی گروه های تکرار و يا آرايه ها را از موجوديت خارج کرده و به موجوديت ديگری منتقل نمائيم . در چنين مواردی ، كليد اصلی موجوديت اول را به عنوان بخشی از كليد اصلی موجوديت جديد قرار داده و با تلفيق يكی ديگر از آيتم های اطلاعاتی موجوديت جديد كه تضمين كننده يكتا بودن ركوردهای آن موجوديت ( جدول ) است ، كليد اصلی موجوديت ايجاد می گردد . بدين ترتيب ، يك ارتباط بين موجوديت پدر و فرزند بر اساس كليد اصلی موجوديت پدر برقرار خواهد شد .
مجددا" به موجوديت "فاكتور فروش " مثال قبل پس از تبديل به فرم اول نرمال توجه نمائيد :
134950
به طور خلاصه می توان گفت كه هدف از فرم اول نرم سازی حذف گروه های تكرار و آرايه ها از موجوديت يا جدول است . فرآيند فوق ، می بايست بر روی تمامی موجوديت های بانك اطلاعاتی اعمال گردد تا بتوان گفت بانك اطلاعاتی نرمال شده در فرم اول است .

فرم دوم نرمال 2NF

موجوديتی در فرم دوم نرمال است که اولا" در فرم اول نرمال باشد و ثانيا" تمامی آيتم های (Attribute) غير کليدی آن وابستگی تابعی به تمام کليد اصلی‌ موجوديت داشته باشند نه به بخشی از آن .همانگونه كه از تعريف فوق استنباط می گردد ، فرم دوم نرمال سازی در خصوص موجوديت هائی بررسی و اعمال می شود كه دارای كليد اصلی مركب هستند ( بيش از يك جزء ) . بنابراين در مثال فوق موجوديت "فاكتور فروش " به خودی خود در فرم دوم نرمال است ولی موجوديت "رديف های فاكتور فروش " كه دارای كليد اصلی مركب است ، نياز به بررسی دارد .
مشکل : در صورتی كه موجوديت در فرم دوم نرمال نباشد ، آنگاه با تغيير اطلاعات قسمت های غيروابسته به تمام كليد ، اين تغييرات در يك ركورد اعمال می شود ولی تاثيری بر روی ساير ركوردها و يا جداول نخواهد داشت . در مثال فوق با تغيير محتوی قيمت واحد در موجوديت "فاكتور فروش " ، قيمت واحد كالا در يك فاكتور فروش اصلاح می گردد اما در ساير فاكتورها اعمال نخواهد شد .
راه حل : برای حل اين مشکل کافی است موجوديت جديدی ايجاد نمائيم و کليد اصلی آن را برابر با آن بخش از کليد اصلی موجوديت مورد بررسی که دارای المان های وابسته به آن است قرار دهيم ، سپس تمام المان های اطلاعاتی وابسته تابعی به اين کليد را از موجوديت مورد بررسی خارج کرده و به موجوديت جديد منتقل نمائيم . در اين حالت بين موجوديت جديد ايجاد شده و موجوديت نرمال شده ، بر اساس کليد اصلی موجوديت جديد ايجاد شده يک ارتباط پدر فرزندی تعريف خواهد شد . دقت کنيد که بر عکس نرمال سازی فرم اول ، در اين جا موجوديت موردبررسی فرزند بوده و موجوديت جديد پدر خواهد بود .
به مثال فوق برمی گرديم و فرم دوم نرمال سازی را بر روي آن اعمال می نمائيم . موجوديت "فاکتور فروش" دارای کليد مرکب نيست پس در فرم دوم نرمال بوده و نياز به بررسی ندارد ، اما موجوديت "رديف های فاکتور فروش" نياز به بررسی دارد . در اين موجوديت آيتم اطلاعاتی "قيمت واحد" وابستگی تابعي به آيتم کالا دارد که بخشی از کليد است نه کل کليد ، پس لازم است تا اين موجوديت را تبديل به فرم دوم نرمال نمائيم . بدين منظور موجوديتی به نام "کالا" ايجاد کرده ، کليد اصلی آن را برابر کالا قرار داده و آيتم قيمت واحد را از موجوديت رديف های فاکتور فروش خارج نموده و به اين موجوديت منتقل می نمائيم. مثال فوق پس از تبديل به فرم دوم نرمال به شکل ذيل خواهد بود :
134951
فرم سوم نرمال 3NF

موجوديت و يا جدولی در فرم سوم نرمال است که اولا" در فرم دوم نرمال بوده و ثانيا" تمام آيتم های غير کليد آن وابستگی تابعی به کليد اصلی داشته باشند ، نه به يک آيتم غير کليد .
مشکل : در صورتی كه موجوديتی در فرم سوم نرمال نباشد ، آنگاه با تغيير آيتم يا آيتم های اطلاعاتی غير وابسته به کليد اصلی در يک رکورد، تغييرات در ساير رکوردها اعمال نخواهد شد و دچار دوگانگی اطلاعات خواهيم شد (مثلا" يک مشتري با دو نام متفاوت) .
راه حل : کافی است آيتم های غير کليدی به هم وابسته را به موجوديت جديدی منتقل و کليد اصلی موجوديت جديد را تعيين نمائيم ، آنگاه کليد اصلی موجوديت جديد را در موجوديت نرمال شده به عنوان يک کليد خارجی (Foreign Key) در نظر گرفت . در موجوديت "فاکتور فروش" مثال فوق آيتم نام مشتری وابستگی تابعی به آيتم کد مشتری دارد که خود يک آيتم غير کليد است بنابر اين بايد نرمال سازی فرم سوم در خصوص آن اعمال شود . شکل ذيل نحوه انجام اين كار را نشان می دهد :

134952
فرم بويس کد نرمال BCNF

فرم بويس کد دارای مفهوم جامع تری نسبت به فرم دوم و سوم نرمال است . در فرم دوم و سوم نرمال بحث بر سر وابستگی تابعی آيتم های غير کليدی به کليد اصلی است . اما در فرم بويس کد ، موجوديتی در فرم بويس کد نرمال است که اولا" در فرم اول نرمال بوده و ثانيا" تمام المان های غير کليدی آن کاملا" وابسته تابعی به يک کليد باشند و نه چيز ديگر . نکته حائز اهميت در اين فرم اين است که بحث بر سر وابستگي تابعی با يک کليد است نه فقط کليد اصلی. مفهوم فوق در خصوص موجوديت هائی که دارای چندين کليد هستند (Alternate Key) مطرح می شود .
فرم چهارم نرمال 4NF

اين فرم در خصوص موجوديت هائی است که ارتباط بين المان های آن يک ارتباط چند ارزشه و يا چند به چند باشد . به عنوان مثال ، موجوديت کلاس درس می تواند شامل چندين دانش آموز و چندين معلم باشد. در چنين مواردی ارتباط بين معلم و دانش آموز يک ارتباط چند به چند می باشد . در اين حالت با ايجاد يك موجوديت رابط مابين موجوديت های مذكور، مشکل ارتباط چند به چند حل خواهد شد (بسياری از سيستم های مديريت بانک های رابطه ای نظير MSSQL از رابطه چند به چند پشتيبانی نمی نمايند ، يعنی نمی توان بين دو جدول يک رابطه چند به چند ايجاد نمود). معمولا" تمام المان های موجوديت رابط ايجاد شده بخشی از كليد اصلی است .
خلاصه

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


منبع : https://rasekhoon.net/Article/Show-19674.aspx

Rasool-GH
شنبه 14 شهریور 1394, 13:41 بعد از ظهر
سلام هیچ کس به نرمال سازی علاقه نداره عایا

جناب امیری لطف میکنید مطالب اقای پیروزمهر رو از حالت مخفی خارج کنید ؟

New Account
چهارشنبه 25 شهریور 1394, 20:34 بعد از ظهر
سلام Rasool-GH

در متن پیغام خصوصیتون اشاره نکردید که سئوال چیه , اینجا هم مطالبتون خیلی پراکندست و تصور میکنم درج دوباره سئوالتون کمک بزرگی خواهد بود ( نمی دونم سئوالات باقی موندوتون کدوم هاست )

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

موفق باشید

Rasool-GH
پنجشنبه 26 شهریور 1394, 20:53 بعد از ظهر
سلام مجدد
یکی از مواردی که در ابتدای بحث نرمال سازی مطرح شد جدا کردن جداول به تفکیک اطلاعات دسته بندی شده است ولی این اقدام به نظر بنده مشکلی رو در انتها در امر تهیه گزارش ایجاد میکند که راه حل اون رو نمیدونم .
به طور مثال

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

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

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

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

New Account
پنجشنبه 26 شهریور 1394, 23:08 بعد از ظهر
سلام Rasool-GH

قبل از ورود به سئوال شما , اشکال فرمت گزارش گیری ذیل چیه ؟

وقتی که فقط یک نام رو فیلتر کنید :

135297

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

135298

( فرمت بالا تغییر داده شده گزارش خود شماست )

موفق باشید

Rasool-GH
جمعه 27 شهریور 1394, 10:18 قبل از ظهر
سلام
یک نمونه دیگه با ریپورت جدید ضمیمه کردم شاید مورد سوال بنده بهتر مشخص بشه .
در نمونه مشاهده میکنید که حاصل گزارش که در نهایت باید روی یک فرم پرینت بشه در گزارش رکورد گرا مشکلی نداره و مقصود براورده میشه در حالی که در گزارش نرمال شده امکان تجمیع اطلاعات در یک فرم از دست میره . این مشکل وقتی بیشتر بروز میکنه که از جدول دیگه ای به طور مثال بخوایم نام فرزندان فرد رو استخراج کنیم و در همین فرم اونها رو هم داشته باشیم

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

New Account
جمعه 27 شهریور 1394, 17:29 بعد از ظهر
سلام rasool-gh

از ابتدا به انتها بیام بهتره


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

تغییر فرم در نهایت با صدور یک تغییر در مدرک وارده که الزاماً این کار در هر سازمانی امکان پذیره
گو اینکه در ممیزی نیز حداکثر توسط ممیز در صورت کشف عدم تطابق ظاهری بین فرم جاری و مستندات مرجع , منجر به یک OBS خواهد شد و نه CAR

:.:.:.:.:.:.:.:.

من اصلا متوجه منظورتون در خصوص اصطلاح رکورد گرا در داخل اکسس نمیشم , اگه منظورتون Record Oriented هستش , جای مطرح کردنش در اینجا نیست
فرمودید :


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

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

:.:.:.:.:.:.:.:.:.

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

:.:.:.:.:.:.:.:.:.


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

با تفسیری که بنده از کلمه سیستماتیک دارم , ما چیزی به اسم روش سیستماتیک , در این مبحث نداریم , شاید در برخی بخشها , Wizard ها رو بشه نمودی از راهکارهای سیستماتیک معرفی کرد , ولی در اینجا موضوعیتی ندارند

در رابطه با استاندارد سازی باید به این نکته توجه داشته باشید که کل قواعد این مبحث ( نرمال سازی ) الزامی نیستند و تنها در حد توصیه قرار دارند
نرمال سازی مزایایی داره و در کنارش معایبی ولی به روشی از استخراج و کنترل اطلاعات اشاره داره که لزوما تنها راه کار نیز نیست ( ولیکن در اکثر موارد هوشمندانه ترین راهکاره )
خیلی از بانکهای اطلاعاتی رو میشه دید که بدون حتی یک ارتباط در سطح جدول , طراحی و پیاده سازی شدند
استفاده از سری توابع Domain Aggregate ( که Dlookup نیز یکی از اونهاست ) در داخل Select Query ها در وضعیتی که تعداد رکوردهای هدف زیاد باشه , اصلا مطلوب نیست ولیکن یکی از راه حلهاست

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

مبحثی که ندیدم این تالار به اون ورود داشته باشه مبحث Sub Query هستش

در مبحث Sub Query با فرایندی غیر متعارف از به کارگیری یک پرس و جو در داخل یک پرس و جوی دیگه آشنا خواهید شد
قدرت واقعی پرس و جوها در این مبحث نهفته هستش , اگر مساله ای در سطح Query ها توسط این فرایند قابل حل نباشه , غیر ممکن خواهد بود که شما با کاربردهای عادی پرس و جوها بتونید به راه حل دست پیدا کنید

Sub Query ها قدرتمند هستند ولی به همون نسبت , هم در پیچیدگی کاربرد و هم در درک پروسه همراه هستند که همین امر یادگیری و آموزش کلی اون رو دشوار میکنه ولیکن مطالعه اون رو به شما توصیه میکنم

:.:.:.:.:.:.:.:.:.:.:.:.

تصور میکنم از همون روش قالب بر Report1 استفاده کنید ( حالا هم اسمی میخواید روی اون روش بذارید ) , این روش استاندارد تر از روش دومتونه

پی نوشت یک :

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

پی نوشت دو :

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

موفق باشید

Rasool-GH
جمعه 27 شهریور 1394, 21:02 بعد از ظهر
سلام . جناب پیروزمهر .


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

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

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



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


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

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



تصور میکنم از همون روش قالب بر Report1 استفاده کنید ( حالا هم اسمی میخواید روی اون روش بذارید ) , این روش استاندارد تر از روش دومتونه

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



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

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



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

در پایان
بحث قالب ثابت فرم رو به همین منظور مطرح کردم . در این روش که شما اقدام به دسته بندی کردید باید اطلاعات رو در ریپورت به قسمتهای Page Header و Code Header و Details تقسیم کرد در حالی که فرم مورد نظر رو نمیشه در این سه بخش تفکیک شده تقسیم کرد .

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

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

در گام اول :
تعداد 3000 دستگاه الکتریکی داریم که مشخصات فنی اون شامل 50 ایتم (نام . نوع . شماره سریال . سال تولید ...) هست و به این دستگاه یک کنتور و متعلقات مربوطه (مشخصات شامل 20 ایتم) و تعدادی کابل در ورودی (از 1 تا 5 کابل) و تعدادی کابل خروجی (از 1 تا 20 کابل) متصل میشه که مشخصات هر کابل به تنهایی شامل 10 ایتم میشه . کلیه این مشخصات یعنی تمام ایتمهای دستگاه و کابلها و کنتور باید روی یک فرم قابل مشاهده و پرینت باشه . من برای این منظور یک جدول ساختم و همه این موارد رو در یک رکورد ذخیره و بازیابی میکنم (کاملا روشنه که تعداد بسیار زیادی از فیلدهای هر رکورد خالی میمونه ). در مبحث استاندارد سازی کاملا واضح هست که برای ذخیره این اطلاعات حداقل 3 جدول مجزا مورد نیازه . یکی برای دستگاه یکی برای کنتور و بعدی برای کابلها.
مشکل همینجاست که اگه مشخصات رو در سه جدول بشکنم نمیتونم همه اونها رو در هنگام چاپ فرم در یک رکورد واحد تجمیع کنم و روی فرم بیارم .
(نتیجه اینکه یا باید با روشی بتونم همه اطلاعات رو در یک رکورد تجمیع کنم و ریپورت رو طبق روال سابق طراحی کنم یا در گزارشگیر و طراحی ریپورت امکانی برای این کار وجود داره که بنده از اون بی اطلاع هستم و راهنمایی و اموزش دوستان رو میطلبه )

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

New Account
شنبه 28 شهریور 1394, 20:31 بعد از ظهر
سلام Rasool-Gh


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

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

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

شما یک گزارش اصلی دارید در داخل اون در قالب یک Sub Report اطلاعات فرضا کنتور و در قالب یک Sub Report دیگه اطلاعات مربوط به کابلها و ... به نمایش درخواهید آورد

الزام شما در تلفیق کل اطلاعات در داخل یک رکورد رو متوجه نمیشم


خدانگهدار

Rasool-GH
شنبه 28 شهریور 1394, 21:10 بعد از ظهر
سلام . بنده با Sub Report کار نکردم . شاید پاسخگوی نیاز من باشه . ممنون بابت زمانی که اختصاص دادید .

بعد از بررسی Sub Query و Sub Report اگر به نتیجه نرسیدم باز هم زحمت میدم .

باز هم ممنون میشم اگر از هر دو موضوع بالا نمونه ای در اختیار بنده بزارید

Rasool-GH
یکشنبه 05 مهر 1394, 21:16 بعد از ظهر
سلام مجدد .
جناب پیروز مهر در موارد ذکر شده مطالعه کردم ولی به جواب نرسیدم .
نمونه فایلی از پروژه خودم ضمیمه کردم . ممنون میشم اگر هر یک از دوستان بتونه راهنمایی کنه .
در فایل ضمیمه شده فرم شناسنامه برای ورود اطلاعات هست و فرمی که اخر اسمش P داره برای پرینت استفاده شده . برای نمونه نرمال سازی جدول کابل رو از داخل جدول شناسنامه خارج کردم . حالا به وسیله دو جدول تفکیک شده چطور میتونم به نمونه خودم برسم
(( البته در گام بعدی به موضوع نرمال کردن جدول بارگیری میرسیم که کمی پیچیده تر خواهد شد ))

Rasool-GH
دوشنبه 06 مهر 1394, 23:14 بعد از ظهر
سلام مجدد .
موردی به نظرم رسیده که روش انجامش رو نمیدونم .
مطابق فایل ضمیمه چطور میتونم در فرم frmNormal تعیین کنم که مثلا در تکس باکس خروجی 1 اطلاعاتی رو نمایش بده که شماره خروجیش در کوئری 1 هست ؟