cris
2017/09/25, 17:49
قبل از ورود به مرحله ی ایجاد جدول ها و نوشتن کد، در ابتدا باید زمانی را به توسعه ی یک مدل داده ی منطقی اختصاص دهند که حداقل سومین فرم نرمال را به دست می آورد.
توضیح مدل سازی داده های منطقی جایی است که در آن ورودی های تجاری، مولفه های آن (ستون ها) و چگونگی ارتباط داخلی ورودی ها با یکدیگر که در نهایت جدول خواهند شد، را تعریف می کنید. این گام اولیه شامل پروسه ی هنجارسازی (Normalization) می شود. در هنجارسازی شما ورودی های خود را شکسته و حشو (redundancy) را از آنها حذف می کنید، هر گونه تکرار داده را نیز حذف کرده و ئر نهایت هر ماهیت (entity) دارای یک کلید اصلی می باشد که همه ی مولفه ها تنها به این کلید تکیه می کنند. این فرایند معمولا از طریق ابزار اعمال نفوذ (leveraging) مدل سازی داده اجرا می شود که می تواند مدل را تجسم کند.
سه مدل هنجارسازی پایه مجود دارد:
اولین فرم نرمال (1 NF) (یک کلید اصلی شناسایی می شود، ویژگی ها به کوچکترین شکل مولفه کاهش می یابند، تکرار داده شناسایی شده و حذف می شود.)
دومین فرم نرمال ( 2NF) ( ویژگی های بدون کلید اصلی که وابسته به کلید اصلی کل نیستند، حذف می شوند.)
سومین فرم نرمال (3NF) وِیژگی های بدون (non-primary key attributes)کلید اصلی که دارای وابستگی به ویژگی های دیگری از نوع خود می باشند، حذف می شوند.
فرم های نرمال دیگری از جمله Boyce-Codd(BCNF) ، چهارمین فرم نرمال (4NF) و پمجمین فرم نرمال (5NF) و غیره وجود دارند. من فکر می کنم دسترسی به سومین فرم نرمال کافیست، اما ممکن است نظر شما این نباشد.
دلیل تلاش برای طبیعی و هنجار کردن (Normalize) چیست؟ این امر می تواند به کاهش تعداد داده ها در جدول کمک کند که منجر به I/Os کمتر در بازیابی (retrieve) داده برای بررسی می شود و باعث ذخیره حجم حافظه در SQL Server نیز می شود. همچنین می تواند مانع پیامدهای با ناهنجاریهایی در اصلاح داده شود که در چنین پیامدهای ناهنجاری ممکن است موضوع در یک ستون آپدیت شود، در حالیکه در ستون دیگر حذف می شود. اخیرا برقراری یکپارچگی ارجاعی (referential integrity) مانند ارزیابی کلید خارجی آسانتر شده است.
بسته به طراحی شما، ممکن است یک پنالتی عملکرد برای طبیعی ساختن تا 3NF وجود داشته باشد و علاوه بر این ممکن است JOIN های زیادی لازم باشند تا درخواست یک بررسی را خرسند سازند. این مسئله نباید مانع شما در طراحی حداقل 3NF شود. اگر یک موضوع بررسی بعدا شناسایی شود، شما گزینه ی معرفی حشو کنترل شده را در طراحی خود دارید. در این فرایند به طور مشخص حشو را برای حل یک اجرا معرفی می کنید. به هرحال به طور خودکار denormalization را به یک طراحی اضافه نکنید. در عوض به یک موقعیت اجرای حقیقی اجازه ی دیکته کردن آن را بدهید.
توضیح مدل سازی داده های منطقی جایی است که در آن ورودی های تجاری، مولفه های آن (ستون ها) و چگونگی ارتباط داخلی ورودی ها با یکدیگر که در نهایت جدول خواهند شد، را تعریف می کنید. این گام اولیه شامل پروسه ی هنجارسازی (Normalization) می شود. در هنجارسازی شما ورودی های خود را شکسته و حشو (redundancy) را از آنها حذف می کنید، هر گونه تکرار داده را نیز حذف کرده و ئر نهایت هر ماهیت (entity) دارای یک کلید اصلی می باشد که همه ی مولفه ها تنها به این کلید تکیه می کنند. این فرایند معمولا از طریق ابزار اعمال نفوذ (leveraging) مدل سازی داده اجرا می شود که می تواند مدل را تجسم کند.
سه مدل هنجارسازی پایه مجود دارد:
اولین فرم نرمال (1 NF) (یک کلید اصلی شناسایی می شود، ویژگی ها به کوچکترین شکل مولفه کاهش می یابند، تکرار داده شناسایی شده و حذف می شود.)
دومین فرم نرمال ( 2NF) ( ویژگی های بدون کلید اصلی که وابسته به کلید اصلی کل نیستند، حذف می شوند.)
سومین فرم نرمال (3NF) وِیژگی های بدون (non-primary key attributes)کلید اصلی که دارای وابستگی به ویژگی های دیگری از نوع خود می باشند، حذف می شوند.
فرم های نرمال دیگری از جمله Boyce-Codd(BCNF) ، چهارمین فرم نرمال (4NF) و پمجمین فرم نرمال (5NF) و غیره وجود دارند. من فکر می کنم دسترسی به سومین فرم نرمال کافیست، اما ممکن است نظر شما این نباشد.
دلیل تلاش برای طبیعی و هنجار کردن (Normalize) چیست؟ این امر می تواند به کاهش تعداد داده ها در جدول کمک کند که منجر به I/Os کمتر در بازیابی (retrieve) داده برای بررسی می شود و باعث ذخیره حجم حافظه در SQL Server نیز می شود. همچنین می تواند مانع پیامدهای با ناهنجاریهایی در اصلاح داده شود که در چنین پیامدهای ناهنجاری ممکن است موضوع در یک ستون آپدیت شود، در حالیکه در ستون دیگر حذف می شود. اخیرا برقراری یکپارچگی ارجاعی (referential integrity) مانند ارزیابی کلید خارجی آسانتر شده است.
بسته به طراحی شما، ممکن است یک پنالتی عملکرد برای طبیعی ساختن تا 3NF وجود داشته باشد و علاوه بر این ممکن است JOIN های زیادی لازم باشند تا درخواست یک بررسی را خرسند سازند. این مسئله نباید مانع شما در طراحی حداقل 3NF شود. اگر یک موضوع بررسی بعدا شناسایی شود، شما گزینه ی معرفی حشو کنترل شده را در طراحی خود دارید. در این فرایند به طور مشخص حشو را برای حل یک اجرا معرفی می کنید. به هرحال به طور خودکار denormalization را به یک طراحی اضافه نکنید. در عوض به یک موقعیت اجرای حقیقی اجازه ی دیکته کردن آن را بدهید.