پشتیبانی: 09131253620
ارتباط با ما
تلگرام: 09131253620


یکی دیگر از خدمات ما طراحی وب سایتهای واکنشگرا یا Responsive با کیفیت بالا می باشد. برای طراحی این وب سایتها از تکنولوژیهای روز دنیا استفاده می شود.


       
صفحه اصلی  |  فروشگاه ما  |  نرم افزار مدیریت برنامه غذایی رستوران ها  |  seo تضمینی اصفهان  |  ثبت نام  |  طراحی وب سایت در اصفهان  |  برنامه نویسی اصفهان  |  انجام پروژه های پایگاه داده SQL Server  |  انجام پروژه مهندسی نرم افزار  |  انجام پروژه های مالتی مدیا بیلدر  |  در مورد ما  |  انجام پروژه های اکسس Microsoft access  |  نمونه پروژه ها  |  ارتباط با ما  |  اخبار و مقاله  |  انجمن رفع اشکالات مشتریان
برجسته ترین ها
گروه های مقاله ها
HyperLink


پایگاه داده رابطه ای بخش بیست و ششم تاریخ درج: ١٣٩۴/٠٩/٢۴

7-3-3 BCNF و حفاظت وابستگي  

چندين روش انسجام محدويت هاي پايگاه داده را بيان كرديم: محدوديت كليد اصلی، وابستگي هاي عملیاتی، محدوديت هاي كنترلی، اعلان و تریگرها است. امتحان كردن اين محدوديت ها براي به روز كردن پايگاه داده مي تواند با ارزش باشد ، بنابراين روشي طراحي مناسب است كه بتوان محدودیت ها را روی پايگاه داده امتحان كرد. به خصوص اگر امتحان كردن وابستگي عملیاتی بتواند توسط يك رابطه انجام شود، پس هزینه امتحان كردن اين محدوديت پايين مي آيد. ديديم كه تجزيه درBCNF  مي تواند از امتحان كردن وابستگي عملیاتی خاص ممانعت كند. براي نمونه فرض كنيد ظاهرا تغييري در روش عملكرد بانك مان انجام داديم. در شكل 6-25 اين طرح عنوان شده كه يك مشتري ممكن است فقط يك كارمند به عنوان يك شخص بانكدار داشته باشد. اين گروه رابطه cust-banker از مشتري به كارمند چند به يك شده است. تغییر کوچکی که باید ایجاد کنیم این است که یک مشتری ممکن است بیشتر از یک شخص بانکدار داشته باشد، اما غالباً یکی در هر شعبه است.
ممكن است اين طراحی E-R  توسط گروه رابطه cust-banker  چند به چند عملي شود (زماني كه يك مشتري ممكن است بيش از يك بانكدار شخصي داشته باشد) و با اضافه كردن گروه رابطه جديد works-in بين employee و branch جفت هاي employee-branch نشان مي دهد کجا كارمند در شعبه كار مي كند. زماني كه يك شعبه ممكن است كارمند هاي زيادي داشته باشد اما يك كارمند ممكن است در يك شعبه كار كند works-in چند به يك از employee به branch ايجاد مي شود. شكل 7-6 يك زير مجموعه از شکل 6-25 را با این مطالب بیشتر نشان مي دهد. با اين وجود در اين طرح مشكلي وجود دارد. به يك مشتري اجازه مي دهيم كه دو يا چند بانكدار شخصي که در يك شعبه يكسان كار مي كنند داشته باشد چيزي كه بانك اجازه نمي دهد. اين موضوع ما را ملزم می کند که راههاي متفاوتي را براي تغيير طرحE-R  مان بررسي كنیم. به جاي اضافه كردن گروه رابطه works-in گروه رابطه cust-employee را با رابطه سه گانه cust-banker-branch جايگزين مي كنيم كه شامل گروه موجوديت های مشتري،كارمند و شعبه است كه از زوج مشتری و کارمند به شعبه چند به یک است که در شكل 7-7 نشان داده شده است. زیرا این طراحی یک گروه رابطه تک برای نمایش محدودیت را ممکن می سازد، این یک مزیت بزرگ نسبت به موردی است که قبلاً در مورد آن بحث کردیم.
 شکل 7-6 گروههای رابطه cust-banker و works-in
شکل 7-6 گروههای رابطه cust-banker و works-in

با این حال، مقايسه بين اين دو رويكرد مشخص نيست. اين الگو از  cust-banker-branch گرفته شده است.
Cust-banker-branch = (customer-id, employee-id, branch-name ,type)    
چون يك كارمند مي تواند فقط در يك شعبه كار كند، مي دانيم در رابطه روی الگوی             cust-banker-branch فقط می تواند یک مقدار branch-name مرتبط با هر مقدار employee-id وجود داشته باشد. داریم:
                                                 Branch-name  -> Employee-id 
به هر حال مجبوريم كه شماره شعبه كارمند را يكبار در هر زمان در رابطه Cust-banker-branch  تكرار كنيم. ديديم كه Cust-banker-branch در BCNF نيست زيرا شماره شناسايي کارمند يك سوپركليد نيست. قانون مان را براي تجزيه BCNF به اين شكل دنبال مي كنيم:
(customer-id , employee-id , type)
(employee-id , branch-name)

اين طرح دقيقا مثل اولين رويكرد در استفاده از رابطه works-in مي باشد که به اجرا در آوردن این محدودیت را که یک کارمند ممکن است اکثراً یک بانکدار شخصی در یک شعبه معین داشته باشد را مشکل می کند. مي توانيم محدوديت را توسط وابستكي عملیاتی به اين شكل نشان دهيم:
customer-id , branch-name -> employee-id
 شکل 7-7 گروه رابطه cust-banker-branch
شکل 7-7 گروه رابطه cust-banker-branch

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

7-3-4 سومين شكل نرمال
دو گزینه اول مشابه دو گزینه در تعريف BCNF هستند. سومين گزينه در تعريف بنظر غير شهودي است، و این آشكار نيست که چرا مفيد است. در حال حاضر در بعضي مفاهيم كاهش حداقل شرايط BCNF در هر الگويي كه حافظ وابستگي تجزيه به 3NF را دارد اطمينان مي دهد. وقتي مطالعه تجزيه به 3NF را شروع كنيم هدف واضح تر مي شود.
توجه کنید که هر الگویی که BCNF را متقاعد کند 3NF را هم متقاعد می کند، چون هر الگويي متقاعد كننده دو تاي اول گزينه ها است. بنابراين BCNF  شكل نرمال محدودتري از 3NF مي باشد.
تعریف 3NF وابستگی های عملیاتی قطعی که در BCNF مجاز نبودند را مجاز می شمارد. یک وابستگی aàb که فقط گزینه سوم از تعریف 3NF را متقاعد می کند در BCNF مجاز شمرده نمی شود، اما در 3NF مجاز است.
اكنون دوباره cust-banker-branch و وابستگي عملیاتی كه منجر می شود الگو در BCNF نباشد را مورد بررسي قرار مي دهيم. توجه كنيد كه در اينجا
 
 مي دانيم كه به علاوه وابستگي هاي عملیاتی 
employee-id -> branch-name
Customer-id, branch-name -> employee-id
وابستگي عملیاتی زير هم به علت اينكه كليد اصلي هستند در آن جاي مي گيرد.
Customer-id, employee-id -> cust-banker-branch
 اين يك كانديدا ايجاد مي كند(Customer-id,  employee-id). البته این شامل branch-name نيست ، بنابراين نياز داريم ببينيم كه كليد هاي كانديداي ديگري هم وجود دارد. در بر گشت، گروه های صفات (Customer-id, branch-name) کليد كانديدا است. 
يك شماره شناسايي مشتري خاص و يك شماره شعبه خاص معین است، مي دانيم تنها يك شماره شناسايي كارمند مرتبط وجود دارد زيرا 
Customer-id, branch-name->  employee-id
اما بنابراین، برای مقدار شماره شناسايي مشتري و شماره شناسايي كارمند ، مي تواند تنها يك چندگانه cust-banker-branch مرتبط وجود داشته باشد زيرا
Customer-id,  employee-id ->  cust-banker-branch
بنابراين نشان داديم كه Customer-id) و  ( branch-nameيك سوپركليد است. زيرا نه Customer-id و نه branch-name به تنهایی سوپركليد نیستند، (Customer-id,  branch-name) يك كليد كانديدا است. چون اين كليد كانديدا شامل branch-name است، وابستگي عملیاتی قانون 
employee-id -> branch-name در 3NF را نقض نمي كند.
بحث ما درباره اينكه cust-banker-branch در 3NF است تلاش بيشتري را مي طلبد. به خاطر همين دليل و دلايل ديگر بررسي ساختار، رويكرد رسمي، شكلهاي نرمال و تجزيه الگوها مفيد است كه در بخش 7-4 مورد بررسي قرار دهيم.
ديديم كه بايد بين BCNF و 3NF وقتي هيچ حافظ وابستگي در طرح                                   وجود ندارد موازنه اي بر قرار شود.اين موازنه ها بيشتر در بخش 7-5-3 توضيح داده مي شود. در این بخش ما یک نمای کلی از بحث حفاظت وابستگی با استفاده از دیدگاه خارجی داریم که این امکان برا ی ما فراهم  می کند که مزایای BCNF و  3NF را دریابیم.
 
7-3-5 شكلهاي نرمال بیشتر
استفاده از وابستگي هاي عملیاتی تجزيه الگوها ممكن است براي جلوگيري از تكرار غير ضروري اطلاعات در موارد خاص كافي نباشد. با يك تغيير جزيي در موجويت employee ملاحظه مي كنيم كه اجازه مي دهد كارمندها چندين شماره تلفن داشته باشند، و بعضي ممكن است بین چندين كارمند مشترك باشد. پس شماره تلفن صفت چند مقداری است و به دنبال قوانين ما براي ایجاد الگوها از طرح E-R ، دو الگو داريم، يكي براي هر صفت چند مقداری مثلtelephone-number و dname :
(employee-id, dname)
(employee-id, telephone-number)
      اگر اين دو الگو را با هم تركيب كنيم نتيجه اي در BCNF پيدا مي كنيم زيرا تنها وابستگي هاي عملیاتی غیر بدیهی در آن جاي دارند. به اين علت ممكن است فكر كنيم چنين تركيباتي ايده اي خوب است. با اين وجود چنين تركيبي ايده اي بدي است، ما مي توانيم توسط مثالي از كارمند با دو وابسته و دو شماره تلفن آن را بررسي كنيم. مثلا كارمند با Employee-id: 999-99-9999  دو اسم وابسته دارد ديويد و ويليام و دوشماره تلفن 512-55-1234 و 512-555-4321. در الگوي تركيب شده، بايد شماره تلفن را يكبار براي هر وابسته تكرار كنيم:
(999-99-9999 , david ,512-55-1234)
(999-99-9999, david ,512-55-4321)
(999-99-9999,william  ,512-55-1234)
(999-99-9999,william  ,512-55-4321)
اگر شماره تلفن را تكرار نكنيم و تنها اولين و آخرين چندگانه را ذخيره كنيم، ما اسم هاي وابسته و شماره هاي وابسته را ثبت خواهيم كرد، اما چندگانه هاي بدست آمده نشان مي دهد كه ديويد با اين شماره مطابقت دارد 512-55-1234 در حاليكه ويليام  با اين شماره 512-55-4321 مطابقت دارد. مي دانيم كه اين نادرست خواهد بود.
چون شكلهاي نرمال بر اساس وابستگي هاي عملیاتی كه به اين موقعيت ها مربوط است كافي       نمي باشد، وابستگي هاي ديگر و شكل هاي نرمال معين مي شوند. در بخشهاي 7-7 و7-6 این موارد را بررسي خواهيم كرد.
 

 


تگها: BCNF   پایگاه داده   پایگاه داده رابطه ای   جبر رابطه ای   حساب رابطه ای   سوپركليد   نرمال سازی   
 

HyperLink

ارسال نظر در مورد این مطلب
نام :  
آدرس ایمیل :  
متن پیام :  
کد امنیتی :  
   
   
نظری برای نمایش وجود ندارد
 
این مطلب را به اشتراک بگذارید: