14
2015
ﻭﺍﺑﺴﺘﮕﻲ ﻭ ﻧﺮﻣﺎﻝ ﺳﺎﺯﻱ
ﻭﺍﺑﺴﺘﮕﻲ ﻭ ﻧﺮﻣﺎﻝ ﺳﺎﺯﻱ
نرمال سازی بانک های اطلاعاتی
نرمال سازی ( Normalization ) یا به تعبیری هنجار سازی فرآیندی است در رابطه با بانک های اطلاعاتی که با دو هدف عمده زیر انجام می شود :
-
کاهش افزونگی اطلاعات ، به این معنی که اطلاعات فقط در یک مکان (جدول) ذخیره و در تمام بانک با استفاده از روابط منطقی تعریف شده (Relationship) قابل دسترسی باشد .
-
حفظ یکپارچگی اطلاعات ، به این معنی که اعمال تغییرات بر روی اطلاعات ( نظیر ایجاد ، بهنگام سازی و حذف ) در یک مکان انجام و به دنبال آن آثار تغییرات در تمام بانک مشاهده گردد . برای روشن شدن مفهوم یکپارچگی بد نیست به مثال ذیل توجه نمائید :
فرض کنید در یک بانک اطلاعاتی دارای دو موجودیت کتاب و نویسنده باشیم . هر یک از موجودیت های فوق دارای المان های اطلاعاتی (Attribute) مختص به خود می باشند . به عنوان نمونه موجودیت “کتاب” دارای المان اطلاعاتی نام نویسنده و موجودیت “نویسنده ” دارای المان های اطلاعاتی متعددی نظیر نام نویسنده ، آدرس نویسنده و … باشد . در صورتی که در موجودیت “کتاب” یک رخداد (رکورد) ایجاد نمائیم بدون اینکه نام نویسنده آن را در موجودیت “نویسنده” ایجاد کرده باشیم ، دچار یک ناهمگونی اطلاعات خواهیم شد .
با توجه به اهداف فوق می توان گفت که فرآیند نرمال سازی از ناهنجاری های بوجود آمده به دلیل بروز تغییرات در بانک جلوگیری خواهد نمود . با اعمال فرآیند نرمال سازی ، یک بانک اطلاعاتی کارآ و مطمئن را خواهیم داشت .
فرآیند نرمال سازی ، فرم های متفاوتی دارد که انواع متداول آن به شرح ذیل است :
-
فرم اول نرمال سازی ۱NF
-
فرم دوم نرمال سازی ۲NF
-
فرم سوم نرمال سازی ۳NF
-
فرم بویس کد نرمال سازی BCNF
-
فرم چهارم نرمال سازی ۴NF
فرم اول نرمال ۱NF
موجودیت و یا جدولی در فرم اول نرمال است که تمامی المان های اطلاعاتی آن ( منظور Attribute است ) یکتا و یا اصطلاحا”atomic باشند . برای روشن شدن این موضوع فرض کنید دارای موجودیتی با نام “فاکتور فروش ” باشیم .
فاکتور فروش |
شماره فاکتور(کلید اصلی) تاریخ فاکتور کد مشتری نام مشتری کالای ۱ تعداد کالای ۱ قیمت واحد کالای ۱ . . . کالای n تعداد کالای n قیمت واحد کالای n |
با مشاهده موجودیت فوق متوجه این موضوع خواهیم شد که المان های کالا ، تعداد کالا و قیمت واحد کالا بیش از یک مرتبه در موجودیت وجود داشته و اصطلاحا” یک گروه تکرار را تشکیل می دهند . برای اجرای مدل فیزیکی این موجودیت ناچار خواهیم بود در طراحی جدول آرایه ای به طول ثابت ( به عنوان نمونه با ده عضو ) تعریف و در آن به ترتیب کالای ۱ تا ۱۰ را تعریف نمائیم .
مشکل : طراحی فوق ما را با دو مشکل عمده روبرو خواهد ساخت : اول این که کارائی بانک اطلاعاتی پائین خواهد آمد (اگر در آینده تعداد کالاهای فاکتور فروش بیش از ۱۰ کالا باشد ، آنگاه مجبور خواهیم بود طراحی جدول مربوطه و متعاقب آن نرم افزارهائی که از آن استفاده می کنند را تغییر دهیم ) و مشکل دوم این که بسیاری از فاکتورها لزوما” دارای ۱۰ کالا نیستند و بنابراین محتوی بسیاری از فیلدها در جدول فوق خالی (دارای ارزش Null) خواهد ماند و حجم زیادی از فضای دیسک هدر خواهد رفت .
راه حل : برای حل این مشکل کافی است تمامی گروه های تکرار و یا آرایه ها را از موجودیت خارج کرده و به موجودیت دیگری منتقل نمائیم . در چنین مواردی ، کلید اصلی موجودیت اول را به عنوان بخشی از کلید اصلی موجودیت جدید قرار داده و با تلفیق یکی دیگر از آیتم های اطلاعاتی موجودیت جدید که تضمین کننده یکتا بودن رکوردهای آن موجودیت ( جدول ) است ، کلید اصلی موجودیت ایجاد می گردد . بدین ترتیب ، یک ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر برقرار خواهد شد .
مجددا” به موجودیت “فاکتور فروش ” مثال قبل پس از تبدیل به فرم اول نرمال توجه نمائید :
به طور خلاصه می توان گفت که هدف از فرم اول نرم سازی حذف گروه های تکرار و آرایه ها از موجودیت یا جدول است . فرآیند فوق ، می بایست بر روی تمامی موجودیت های بانک اطلاعاتی اعمال گردد تا بتوان گفت بانک اطلاعاتی نرمال شده در فرم اول است .
فرم دوم نرمال ۲NF
موجودیتی در فرم دوم نرمال است که اولا” در فرم اول نرمال باشد و ثانیا” تمامی آیتم های (Attribute) غیر کلیدی آن وابستگی تابعی به تمام کلید اصلی موجودیت داشته باشند نه به بخشی از آن .همانگونه که از تعریف فوق استنباط می گردد ، فرم دوم نرمال سازی در خصوص موجودیت هائی بررسی و اعمال می شود که دارای کلید اصلی مرکب هستند ( بیش از یک جزء ) . بنابراین در مثال فوق موجودیت “فاکتور فروش ” به خودی خود در فرم دوم نرمال است ولی موجودیت “ردیف های فاکتور فروش ” که دارای کلید اصلی مرکب است ، نیاز به بررسی دارد .
مشکل : در صورتی که موجودیت در فرم دوم نرمال نباشد ، آنگاه با تغییر اطلاعات قسمت های غیروابسته به تمام کلید ، این تغییرات در یک رکورد اعمال می شود ولی تاثیری بر روی سایر رکوردها و یا جداول نخواهد داشت . در مثال فوق با تغییر محتوی قیمت واحد در موجودیت “فاکتور فروش ” ، قیمت واحد کالا در یک فاکتور فروش اصلاح می گردد اما در سایر فاکتورها اعمال نخواهد شد .
راه حل : برای حل این مشکل کافی است موجودیت جدیدی ایجاد نمائیم و کلید اصلی آن را برابر با آن بخش از کلید اصلی موجودیت مورد بررسی که دارای المان های وابسته به آن است قرار دهیم ، سپس تمام المان های اطلاعاتی وابسته تابعی به این کلید را از موجودیت مورد بررسی خارج کرده و به موجودیت جدید منتقل نمائیم . در این حالت بین موجودیت جدید ایجاد شده و موجودیت نرمال شده ، بر اساس کلید اصلی موجودیت جدید ایجاد شده یک ارتباط پدر فرزندی تعریف خواهد شد . دقت کنید که بر عکس نرمال سازی فرم اول ، در این جا موجودیت موردبررسی فرزند بوده و موجودیت جدید پدر خواهد بود .
به مثال فوق برمی گردیم و فرم دوم نرمال سازی را بر روی آن اعمال می نمائیم . موجودیت “فاکتور فروش” دارای کلید مرکب نیست پس در فرم دوم نرمال بوده و نیاز به بررسی ندارد ، اما موجودیت “ردیف های فاکتور فروش” نیاز به بررسی دارد . در این موجودیت آیتم اطلاعاتی “قیمت واحد” وابستگی تابعی به آیتم کالا دارد که بخشی از کلید است نه کل کلید ، پس لازم است تا این موجودیت را تبدیل به فرم دوم نرمال نمائیم . بدین منظور موجودیتی به نام “کالا” ایجاد کرده ، کلید اصلی آن را برابر کالا قرار داده و آیتم قیمت واحد را از موجودیت ردیف های فاکتور فروش خارج نموده و به این موجودیت منتقل می نمائیم. مثال فوق پس از تبدیل به فرم دوم نرمال به شکل ذیل خواهد بود :
ردیف های فاکتور فروش |
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (فاکتور فروش) |
فاکتور فروش |
شماره فاکتور(قسمت اول کلید اصلی) کالا (قسمت دوم کلید اصلی) تعداد |
شماره فاکتور(کلید اصلی) تاریخ فاکتور کد مشتری نام مشتری |
|
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (کالا) | ||
کالا | ||
کالا (کلید اصلی) قیمت واحد |
فرم سوم نرمال ۳NF
موجودیت و یا جدولی در فرم سوم نرمال است که اولا” در فرم دوم نرمال بوده و ثانیا” تمام آیتم های غیر کلید آن وابستگی تابعی به کلید اصلی داشته باشند ، نه به یک آیتم غیر کلید .
مشکل : در صورتی که موجودیتی در فرم سوم نرمال نباشد ، آنگاه با تغییر آیتم یا آیتم های اطلاعاتی غیر وابسته به کلید اصلی در یک رکورد، تغییرات در سایر رکوردها اعمال نخواهد شد و دچار دوگانگی اطلاعات خواهیم شد (مثلا” یک مشتری با دو نام متفاوت) .
راه حل : کافی است آیتم های غیر کلیدی به هم وابسته را به موجودیت جدیدی منتقل و کلید اصلی موجودیت جدید را تعیین نمائیم ، آنگاه کلید اصلی موجودیت جدید را در موجودیت نرمال شده به عنوان یک کلید خارجی (Foreign Key) در نظر گرفت . در موجودیت “فاکتور فروش” مثال فوق آیتم نام مشتری وابستگی تابعی به آیتم کد مشتری دارد که خود یک آیتم غیر کلید است بنابر این باید نرمال سازی فرم سوم در خصوص آن اعمال شود . شکل ذیل نحوه انجام این کار را نشان می دهد :
ردیف های فاکتور فروش |
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (فاکتور فروش) |
فاکتور فروش | ||
شماره فاکتور(قسمت اول کلید اصلی) کالا (قسمت دوم کلید اصلی) تعداد |
شماره فاکتور(کلید اصلی) تاریخ فاکتور کد مشتری (کلید خارجی) |
|||
ارتباط بین موجودیت پدر و فرزند بر اساس کلید اصلی موجودیت پدر (کالا) | ارتباط بین موجودیت پدر ( مشتری ) و فرزند بر اساس کلید خارجی |
|||
کالا | مشتری | |||
کالا (کلید اصلی) قیمت واحد |
کدمشتری (کلید اصلی) نام مشتری |
فرم بویس کد نرمال BCNF
فرم بویس کد دارای مفهوم جامع تری نسبت به فرم دوم و سوم نرمال است . در فرم دوم و سوم نرمال بحث بر سر وابستگی تابعی آیتم های غیر کلیدی به کلید اصلی است . اما در فرم بویس کد ، موجودیتی در فرم بویس کد نرمال است که اولا” در فرم اول نرمال بوده و ثانیا” تمام المان های غیر کلیدی آن کاملا” وابسته تابعی به یک کلید باشند و نه چیز دیگر . نکته حائز اهمیت در این فرم این است که بحث بر سر وابستگی تابعی با یک کلید است نه فقط کلید اصلی. مفهوم فوق در خصوص موجودیت هائی که دارای چندین کلید هستند (Alternate Key) مطرح می شود .
فرم چهارم نرمال ۴NF
این فرم در خصوص موجودیت هائی است که ارتباط بین المان های آن یک ارتباط چند ارزشه و یا چند به چند باشد . به عنوان مثال ، موجودیت کلاس درس می تواند شامل چندین دانش آموز و چندین معلم باشد. در چنین مواردی ارتباط بین معلم و دانش آموز یک ارتباط چند به چند می باشد . در این حالت با ایجاد یک موجودیت رابط مابین موجودیت های مذکور، مشکل ارتباط چند به چند حل خواهد شد (بسیاری از سیستم های مدیریت بانک های رابطه ای نظیر MSSQL از رابطه چند به چند پشتیبانی نمی نمایند ، یعنی نمی توان بین دو جدول یک رابطه چند به چند ایجاد نمود). معمولا” تمام المان های موجودیت رابط ایجاد شده بخشی از کلید اصلی است .
خلاصه
نرمال سازی فرم های دیگری نیز دارد که به دلیل نادر بودن و خاص بودن آنها در این مقاله به آنها اشاره نشده است . آنچه در خصوص نرمال سازی عمومیت دارد تا فرم سوم آن است ، یعنی در هنگام طراحی بانک های اطلاعاتی حتما” می بایست فرآیند نرمال سازی تا فرم سوم را انجام داد .
فرآیند نرمال سازی یک فرآیند تکراری (Recursive) است یعنی پس از هر مرحله نرمال سازی که منجر به ایجاد موجودیت های جدید می گردد ، فرآیند را باید از ابتدا تا انتها بر روی موجودیت های تازه ایجاد شده نیز اجرا نمود.
جدول آنرمال
اگر در جدولی مانند جدول زیر به ازای هر شماره دانشجویی و نام دانشجو ؛ بجای یک شماره تلفن ، چند شماره تلفن وجود داشته باشد جدول آنرمال است.(یعنی اگر شماره ۷۸۰۱ ؛ مورد جستجو قرار گرفت ، دانشجوی آرش با ۲ شماره تلفن بدست می آید؛ در صورتی که باید یکی از دو حالت زیر رخ دهد:
۱: نتیجه جستجو یک رکورد باشد که در آن نام آرش با یک شماره تلفن بدست بیاید
۲: نتیجه جستجو۲ رکورد متفاوت باشد که در اولی نام آرش با شماره تلفن اول و در رکورد دوم نام آرش با شماره تلفن دوم بیاید )
تلفن |
نام دانشجو |
شماره داشجویی |
۶۲۶۲۷۷۸-۰۳۱۱ ۰۹۱۳۳۱۱۵۲۳۴ |
آرش |
۷۸۰۱ |
۲۹۵۶۶۷۷-۰۲۱ ۰۹۱۲۳۱۴۴۵۳۲ |
علی |
۷۸۰۲ |
*نرمال سازی سطح ۱
جدولی نرمال سطح ۱ است که در برخورد هر سطر با ستون به یک مقدار تجزیه ناپدیر برسیم
مثلا در جدول بالا در سطر اول (آرش ۷۸۰۱) و ستون سوم (تلفن) به ۲ شماره دست می یابیم (بخشی که با قرمز پر رنگ مشخص شده) ؛ پس برای تبدیل جدول به نرمال سطح ۱ آن را بصورت زیر در می آوریم
تلفن |
نام دانشجو |
شماره داشجویی |
۶۲۶۲۷۷۸-۰۳۱۱ |
آرش |
نرمال سطح ۱ ۷۸۰۱ |
۰۹۱۳۳۱۱۵۲۳۴ |
آرش |
۷۸۰۱ |
۲۹۵۶۶۷۷-۰۲۱ |
علی |
۷۸۰۲ |
۰۹۱۲۳۱۴۴۵۳۲ |
علی |
۷۸۰۲ |
تعریف نرمال سطح ۱ : زمانی یک جدول نرمال سطح ۱ است که در برخورد هر سطر با هر ستون فقط و فقط به یک مقدار واحد و نجزیه ناپذیر برسیم (مثلا در برخورد سطر اول با ستون تلفن فقط به یک شماره تلفن می رسیم ؛ و همین طور برای سطرهای بعدی )
نرمال سطح ۲ (زمانی برای یک جدول نرمال سازی سطح ۲و ۳و… انجام می دهیم که کلید اصلی آن چند بخشی باشد یعنی چند فیلد باهم کلید اصلی باشند)
مثال : جدول زیر نرمال سطح ۱ بوده ولی نرمال سطح ۲ نیست//« علامت # یعنی کلید»
چون اگر بخواهیم دانشجوی علی با شماره ۷۸۰۱ را از جدول حذف کنیم ؛ اطلاعات درس ریاضی هم ناخواسته حذف می شود و اگر دانشجوی جدیدی ثبت نام کند که هنوز هیچ درسی را نگرفته ؛ نمی توان فیلد شماره درس که جزیی از کلید است را خالی رها کرد.
#ترم |
نمره گرفته شده |
واحد درس |
نام درس |
#شماره درس |
نام |
#شماره دانشجویی |
۲ |
۲۰ |
۳ |
پایگاه داده |
۱۴۰۰ |
علی |
۷۸۰۱ |
۱ |
۱۰ |
۳ |
ریاضی ۱ |
۱۵۰۰ |
علی |
۷۸۰۱ |
۱ |
۲۰ |
۳ |
تجزیه و تحلیل |
۱۶۰۰ |
علی |
۷۸۰۱ |
۱ |
۷ |
۳ |
پایگاه داده |
۱۴۰۰ |
آرش |
۷۹۰۲ |
۱ |
۲۰ |
۱ |
تربیت بدنی |
۱۷۰۰ |
آرش |
۷۹۰۲ |
یک جدول نرمال سطح ۲ است اگر:
۱- نرمال یک باشد
۲- در آن جدول هیچ وابستگی جزیی به کلید اصلی وجود نداشته باشد(هیچ یک از ویژگی های جدول تنها به قسمتی از کلید اصلی وابستگی نداشته باشد) یعنی جستجوی مقداری در جدول به کلیه فیلدهایی که کلید هستند وابستگی داشته باشد.
۳- (وابستگی جزیی : حالتی است که بدست آوردن مقداری در جدول به قسمتی از کلید «نه کل کلید» وابستگی دارد ؛ حالت زیر:
#ترم |
نمره گرفته شده |
واحد درس |
نام درس |
#شماره درس |
نام |
#شماره دانشجویی |
۲ |
۲۰ |
۳ |
پایگاه داده |
۱۴۰۰ |
علی |
۷۸۰۱ |
۱ |
۱۰ |
۳ |
ریاضی ۱ |
۱۵۰۰ |
علی |
۷۸۰۱ |
۱ |
۲۰ |
۳ |
تجزیه و تحلیل |
۱۶۰۰ |
علی |
۷۸۰۱ |
۱ |
۷ |
۳ |
پایگاه داده |
۱۴۰۰ |
آرش |
۷۹۰۲ |
۱ |
۲۰ |
۱ |
تربیت بدنی |
۱۷۰۰ |
آرش |
۷۹۰۲ |
بدست آوردن نام درس فقط به فیلد شماره درس که قسمتی از کلید است وابستگی دارد چون اگر شماره درسی را داشته باشیم میتوان نام آن را بدست آورد و به چیز دیگری نیاز نیست .
)
نرمال سازی سطح۳ :
جدولی نرمال سطح ۳ است که :
۱- نرمال سطح۲ باشد.
۲- در آن جدول ؛ ویژگی هایی که کلید نیستند به هم وابستگی تابعی نداشته باشند
یعنی اگر جدولی نرمال سطح۲ بود و ویژگی های غیر کلیدی آن ؛ به هم وابستگی نداشتند، آن جدول نرمال سطح ۳ است.
برای دانلود فایل کامل آموزش نرمال سازی بر روی لینک کلیک نمایید.
از اینکه حامی پروژه را برای دانلود انتخاب نموده اید، سپاسگزاریم.
مطالب مرتبط
فرستادن دیدگاه
راهنمای دانلود
تبلیغات
آرشیو موضوعی
- کامپیوتر (142)
- آموزشی (30)
- برنامه نویسی متلب (3)
- برنامه نویسی وب (4)
- برنامه نویسی ویندوز (19)
- #C – سی شارپ (18)
- API – اِِی پی آی (6)
- ++C/C سی/سی پلاس پلاس (1)
- #C – سی شارپ (18)
- پایگاه داده (9)
- تحقیقاتی (26)
- سخت افزار (1)
- شبکه های کامپیوتری (28)
- شبیه سازی (7)
- شیوه ارائه مطالب (6)
- طراحی الگوریتم (1)
- طراحی صفحات وب (3)
- CSS – سی اس اس (3)
- HTML – اچ تی ام ال (3)
- کارآموزی (4)
- کامپایلر (2)
- مهندسی نرم افزار (54)
- UML – یو ام ال (51)
- نمونه سوال (3)
- هوش مصنوعی (1)
بیشترین بازدید
- مدلسازی معنایی داده ها - تعداد بازدید (83,916)
- تجزیه و تحلیل سیستم کتابخانه توسط UML - تعداد بازدید (33,139)
- تجزیه و تحلیل سیستم رزرو و فروش بلیط در آژانس مسافرتی با UML - تعداد بازدید (30,528)
- نمودار ER بانک و روابط بین آنها و نرمال سازی جداول در سطح BCNF - تعداد بازدید (27,481)
- نمودار ER کتابخانه و روابط بین آنها و نرمال سازی جداول در سطحBCNF - تعداد بازدید (26,230)
- نمودار جریان داده (Data flow Diagram(DFD آژانس تاکسی تلفنی - تعداد بازدید (26,105)
- تجزیه و تحلیل فروشگاه با UML در نرم افزار رشنال رُز - تعداد بازدید (24,295)
- تجزیه و تحلیل سیستم فروشگاه آنلاین با UML در نرم افزار رشنال رز(Rational Rose) - تعداد بازدید (23,525)
- Checkout - تعداد بازدید (23,452)
- تجزیه و تحلیل سازمان تامین اجتماعی با UML در نرم افزار رشنال رُز - تعداد بازدید (22,174)
مطالب تصادفی
- تجزیه و تحلیل سيستم رستوران و فست فود با UMLو طراحی نمودار جریان داده DFD با Power Designer
- تجزیه و تحلیل سیستم فروش در شرکت با UML با نرم افزار Rational Rose
- تجزیه و تحلیل و طراحی شیء گرا خرید اینترنتی بلیط هواپیما با استفاده از UML در نرم افزار رشنال رُز
- شبیه سازی Task Manager با توابع API در سی شارپ
- ایجاد ویروس New Folder با توابع API در سی شارپ
- شناسایی و اصلاح شکاف های مرزی در شبکه های حسگر بیسیم
- تجزیه و تحلیل سازمان تامین اجتماعی با UML در نرم افزار رشنال رُز
- بررسی و مطالعه انبار داده ها و ویژگی های آن و هوشمندی کسب و کار
- تجزیه و تحلیل ثبت نام عمره مفرده با UML
- نمونه سوال کامپایلر – (۱)SLR
تازه ترین ها
- تجزیه و تحلیل آموزشگاه موسیقی با استفاده از UML
- تجزیه و تحلیل هتل با UML در نرم افزار رشنال رُز
- تجزیه و تحلیل سیستم عابر بانک با استفاده از UML در نرم افزار رشنال رُز
- تجزیه و تحلیل صرف غذا در رستوران با UML در نرم افزار Rational Rose
- تجریه و تحلیل سیستم امنیتی ورود و خروج یک سازمان با UML در نرم افزار Pacestar UML Diagrammer
- تجزیه و تحلیل انبار کارخانه با UML
- تجزیه و تحلیل تاکسی تلفنی با UML
- تجزیه و تحلیل سیستم رزرو و فروش بلیط در آژانس مسافرتی با UML
- تجزیه و تحلیل شرکت کاریابی با استفاده از UML
- تجزیه و تحلیل سیستم کتابخانه توسط UML
تقویم شمسی
ش | ی | د | س | چ | پ | ج |
---|---|---|---|---|---|---|
« آذر | ||||||
1 | 2 | |||||
۳ | ۴ | ۵ | ۶ | ۷ | ۸ | ۹ |
۱۰ | ۱۱ | ۱۲ | ۱۳ | ۱۴ | ۱۵ | ۱۶ |
۱۷ | ۱۸ | ۱۹ | ۲۰ | ۲۱ | ۲۲ | ۲۳ |
۲۴ | ۲۵ | ۲۶ | ۲۷ | ۲۸ | ۲۹ | ۳۰ |