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

[Rasool-GH]

سلام و ممنون
اما در این صورت مهارت دوم فرد گزارش نمیشه

[alirezabahrami]

سلام و ممنون
اما در این صورت مهارت دوم فرد گزارش نمیشه

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

[alirezabahrami]

با سلام مجدد
توضیحات و نمونه پست قبل اصلاح گردید
یا علی

[Rasool-GH]

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

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

[alirezabahrami]

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

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

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

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

[Rasool-GH]

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

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

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

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

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


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

[Rasool-GH]

این مطلب هم در مورد نرمال سازی و شیوه های اونه

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

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

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

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

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

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

4.png
فرم بويس کد نرمال BCNF

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

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

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


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

[Rasool-GH]

سلام هیچ کس به نرمال سازی علاقه نداره عایا

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

[New Account]

سلام Rasool-GH

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

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

موفق باشید

[Rasool-GH]

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

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

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

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

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

[New Account]

سلام Rasool-GH

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

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

Shot A.png

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

Shot B.png

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

موفق باشید

[Rasool-GH]

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

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

[New Account]

سلام 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]

سلام . جناب پیروزمهر .

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]

سلام Rasool-Gh

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

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

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

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

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


خدانگهدار

[Rasool-GH]

سلام . بنده با Sub Report کار نکردم . شاید پاسخگوی نیاز من باشه . ممنون بابت زمانی که اختصاص دادید .

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

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

[Rasool-GH]

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

[Rasool-GH]

سلام مجدد .
موردی به نظرم رسیده که روش انجامش رو نمیدونم .
مطابق فایل ضمیمه چطور میتونم در فرم frmNormal تعیین کنم که مثلا در تکس باکس خروجی 1 اطلاعاتی رو نمایش بده که شماره خروجیش در کوئری 1 هست ؟

[azandi]

سلام خدمت اساتید محترم و تشکر بابت مطالب آموزندتون
من تازه اکسس رو باهاش آشنا شدم و پس از مطالعه این پروژه آموزش رو که شامل درس . مطالب درسی.. دانشجو .. استاد هست رو درست کردم می خواستم ببینم ایردش کجاست؟1.PNG