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


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


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


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

7 -8 فرايند طراحی پايگاه داده ها 

تا اينجا موضوعات جزئي درمورد شكل هاي نرمال و نرمال سازي رامورد بررسي قرارداديم دراين بخش چگونگي تطبيق نرمال سازي با فرايند كلي طرح پايگاه داده ها رامورد مطالعه قرارمی دهيم .
قبلاً دراوايل قسمت 7-3 فرض مي كرديم يك الگوي رابطه اي داده شده است ودرجهت نرمال سازي آن پيش مي رفتيم. چندين راه براي حل الگوي R وجوددارد.
1- R مي تواند از تبديل يك دياگرام E-R  به دسته اي از الگوهاي رابطه اي حاصل شود.
2- R مي تواند يك رابطه منفرد باشدكه شامل تمامي خواص هاي مورد علاقه است سپس فرايند  نرمال سازي را به رابطه هاي كوچكتر تفكيك مي كند.
3-  R مي تواند نتيجه يك طرح ad-hoc از رابطه ها باشدكه آنها را درادامه اين قسمت، مفاهيم اين روش رامورد بررسي قرارمي دهيم.
همچنين برخي ازموضوعات كاربردي دررابطه باطراحی پايگاه داده ها را بررسي مي كنيم كه شامل، از نرمال درآوررن براي اجرا و نمونه هايي ازطراحی بد كه بانرمال سازي كشف نمي شود.
 
7-8-1 مدل E-R و نرمال سازي
هنگامي كه يك دياگرام E-R را به دقت تعريف مي كنيم وتمامي موجوديت ها رامي شناسيم، الگوهاي رابطه اي كه از دياگرام E-R حاصل مي شوند نبايد نيازمند نرمال سازي  بيشتر باشند. به هرحال آنها مي توانند وابستگي هاي عملیاتی بين صفات يك موجوديت باشند بعنوان مثال فرض كنيد موجوديت employee صفتهای department-number و department-address را دارا باشد و يك وابستگي عملیاتی  department-number-> department-address موجود باشد آنگاه لازم است كه رابطه حاصل از employee را نرمال سازي كنيم.
بيشتر نمونه هاي چنين وابستگي هايي از طراحی نامناسب دياگرام E-R ناشي مي شود در نمونه بالا اگر دياگرام را بدرستي طراحي كرده بوديم يك موجوديت department  با صفت department-adress ويك رابطه بين employee و department خلق مي كرديم. بطورمشابه رابطه با بيش ازدو موجوديت ممكن است درشكل نرمال مورد نظر وجود نداشته باشد.
ازآنجا كه بيشتر رابطه ها دوتايي است اين موارد نسبتاً به ندرت اتفاق مي افتد .(درحقيقت برخي از گونه هاي دياگرام E-R در واقع تعيين روابط دوجانبه رامشكل ياغيرممكن مي كند).
وابستگي هاي عملیاتی مي تواند براي كشف طرح E-R  نامناسب، به ماكمك كند. اگر روابط حاصله در شكل نرمال مورد نظر موجود نباشند مشكل در دياگرام E-R  ثابت مي شود اين بدان معني است كه  نرمال سازي مي تواند بطور رسمي به عنوان قسمتي ازمدل سازي داده ها انجام شود.
 نرمال سازي مي تواند مکرر به طراح در هنگام مدل سازي E-R واگذار شود ورسما برروي روابط حاصل ازمدل E-R انجام شود.
يك خواننده بادقت ملاحظه مي كند كه به منظور شرح نيازمندي وابستگي هاي چند مقداري وشكل نرمال چهارم، مجبور هستيم با الگوهايي شروع كنيم كه از طرح E-R خودمان ناشي نشده اند درواقع فرايند ايجاد يك طرح گرايش به ايجاد طرح هاي 4NF دارد. اگر يك وابستگي چندمقداري وجود داشته باشد و بر وابستگي عملیاتی مربوطه دلالت نكند اين وابستگي از يكي ازمنابع زير ناشي مي شود:
يك رابطه چند به چند
يك صفت چند مقداري از يك دسته موجوديت 
براي يك رابطه چند به چند هر موجوديت مربوط الگوي خود را داشته ويك الگوي ديگر براي دسته روابط موجوداست . براي يك صفت چند مقداري يك الگوي جدا ايجاد شده كه از آن صفت وكليد اوليه دسته موجوديت تشكليل شده است (همانند صفت department-name از دسته موجودیت employee).
روش رابطه کل براي رسيدن به طرح پايگاه داده هاي رابطه اي بايك فرض شروع مي شود كه يك الگوي رابطه اي منفرد شامل تمامي صفات مورد نظر است. اين الگوي منفرد معين مي كند كه چگونه کاربران و برنامه های کاربردی با پايگاه داده ها رابطه برقرار می کنند.


7-8-2 نام گذاري صفات و رابطه ها 
يك ويژگي مطلوب براي يك طرح پايگاه داده فرض تك نقشي بودن است، يعني هر صفت يك معناي واحد داشته باشد. اين ويژگي باعث مي شودكه از صفت مشابه براي معاني مختلف در الگوهاي متفاوت استفاده استفاده نكنيم. بطور مثال ممكن است صفت number را هم براي loan-number درالگوي loan و هم برای account-number در الگوی account در نظر بگیریم. اتصال يك رابطه از الگوي loan  بايك رابطه از الگوي account بي معني است (اطلاعات جفت loan-account در جائيكه loan وaccount یک شماره يكسان دارند) هنگاميكه استفاده كنندگان و درخواست كنندگان به دقت كارمي كنند تااستفاده            صحيح ازهرپيشامد راتضمين كنند داشتن يك نام متفاوت براي loan-number و account-number   باعث می شود خطاهاي مصرف كنندگان كاهش يابد. درحقيقت فرض تك نقشي درطرح هاي پايگاه داده دراين كتاب را مشاهد كرده ايم و اين يك تمرين كلي خوب است.
  درحاليكه گذاشتن نام هاي متمايز براي خواص ناسازگار يك ايده خوب است، استفاده از اسم يكسان براي خواص رابطه هاي مختلف كه معناي يكسان دارند نيز مفيد است. بطور مثال نام                customer-idوemployee-id را دردسته موجوديت هاي customer وemployee بكار مي بريم. اگربخواهيم اين دسته موجوديت ها را با ايجاد يك دسته موجوديت person تعميم دهيم، بايد اين صفت را دوباره نامگذاري كنيم. بنابراين حتي اگر درحال حاضر يك تعميم سازي از customer وemployee نداشته باشيم وپيش بيني چنين احتمالي رابكنيم بهتر است كه درهردودسته موجوديت از اسم يكساني استفاده كنيم. اگرچه ترتيب نام صفات دريك الگو ازلحاظ تكنيكي بي اهميت است، معمولا صفات مهمتر را اول ذكر    مي كنند. اين كارخواندن را آسان تر مي كند. 
درالگوهاي پايگاه داده بزرگ، دسته رابطه ها (والگوهايي كه از آنها مشتق مي شوند) اغلب ازطريق تسلسل نام هاي دسته موجوديت هاي مربوط نام گذاري مي شوند. كه ممكن است با يك خط تيره يا خطي درزير آن همراه باشد. ما ازتعداد كمي از اين نام ها استفاده كرده ايم ،مانندloan-branch وaccount-branch. ما از نام هاي borrower و depositor به جاي نام هاي طولاني مثل customer-loan وcustomer-account استفاده كرديم. از آنجائيكه يادآوري موجوديت هاي مربوط براي تعداد كمي از رابطه ها آسان است اين كار مقبول است. هميشه نمي توانيم اسامي روابط را با يك سري ساده ايجاد كنيم، مثلا رابطه بين manager يا works-for با employee را اگرemployee-employee  بناميم بي معني خواهد بود. همچنين اگر چندين دسته رابطه ممكن بين يك جفت دسته موجوديت وجود داشته باشد، اسامي روابط شامل قسمت هايي اضافي براي تشخيص رابطه هاست. سازمان هاي مختلف روش هاي متفاوتي برای    نام گذاري موجوديت ها دارند. بطور مثال يك دسته موجوديت مشتري ها را customer يا customers  بناميم. شكل مفرد آنرا در طرح هاي پايگاه داده خود استفاده كرديم. هم شكل مفرد و هم شكل جمع آن قابل قبول است. 
با طولاني تر شدن الگوها و افزايش تعداد رابطه ها، استفاده نامتناقض از نامگذاري خواص، روابط و موجوديت ها كار را براي طراحان پايگاه داده و برنامه ريزان درخواست نامه بسيار راحت تر مي كند.


7-8-3 از نرمال در آوردن براي کارآیی  
 گهگاه طراحان پايگاه داده الگويي را انتخاب مي كنند كه اطلاعات زائد دارد، يعني نرمال سازي نشده است. آنها از زوائد و حشويات استفاده مي كنند تا کارایی را براي برنامه های کاربردی ويژه اي اصلاح كنند . تاوان استفاده نكردن از الگوهاي نرمال كار فوق العاده اي است كه براي حفظ اطلاعات زائد بايد انجام دهند (از نظر زمان كد گذاري و زمان اجرا ) بطور مثال، فرض كنيد كه نام دارنده حساب بايد هميشه همراه با شماره حساب وموجودی  نمايش داده شود . در الگوي نرمال ما، اين عمل نيازمند پيوند depositor باaccount  است.
روش ديگر براي حساب كردن پيوند ذخيره رابطه اي است كه شامل تمامي خواص depositor و account است. اين كار نمايش اطلاعات حساب را سرعت مي بخشد. به هر حال موجودی اطلاعات براي يك حساب براي هر فردي كه صاحب حساب است تكرار ميشود. هر زمان كه موجودی حساب به روز مي شود و تمامي كپي ها نيز بايد بوسيله برنامه کاربردی به روز شوند. فرايند انتخاب يك الگوي نرمال و از نرمال در آوردن آن denormalization نام دارد و طراحان از آن براي ميزان كردن اجراي سيستم استفاده مي كنند تا عمليات يك روش بهتركه امروزه توسط اكثر سيستم هاي پايگاه داده پشتيباني        مي شود، استفاده از الگوهاي نرمال سازي شده و به علاوه ذخيره پيوند account و depositor به عنوان يك دیدگاه خارجی است. (به ياد داشته باشيد كه دیدگاه خارجی دیدگاهی است كه نتيجه اش در پايگاه داده ذخيره شد و هنگاميكه روابط استفاده شده در آن به روز مي شوند، خود نيز به روز شود) استفاده از دیدگاه خارجی، همانند از نرمال در آوردن ، زمان و مكان دارد؛ اما داراي اين مزيت است که به روز نگه داشتن دیدگاه كار سيستم پايگاه داده است نه كار برنامه نویس. 

7-8-4 ديگر مباحث طراحی  
برخي از جنبه هاي طراحی پايگاه داده هستند كه نرمال سازي متوجه آنها نيست و بنابراين مي توانند منجر به طرح پايگاه داده بدي شوند. اطلاعاتي كه به يك زمان يا بازه زماني متعلق هستند. نمونه هايي را در اينجا مياوريم:  واضح است كه از چنين طرح هايي بايد پرهيز شود. پايگاه يك شركت را، كه مي خواهيم در آن درآمدهاي شركت را در سال هاي مختلف ذخيره كنيم، در نظر بگیرید. رابطه earning(company-id, year, amount)  مي تواند براي ذخيره اطلاعات درآمدها استفاده شود. تنها وابستگي عملیاتی در اين رابطه مي باشد employee-id , year  amount است و اين رابطه نیز در BCNF  است. طرح ديگر استفاده از روابط چندگانه است، كه هر كدام درآمدهاي يك سال متمايز را ذخيره كنند . فرض كنيم سال هاي مورد نظر سال هاي 2000 و 2001و 2002 هستند. پس رابطه هائی به شکل earnings-2000 و earning-2001 و earning-2002 داریم که همه آنها در الگو هستند. در اينجا تنها وابستگي عملیاتی در هر رابطه company-id  earnings خواهد بود، پس اين رابطه ها نيز در BCNF هستند. هنوز اين طرح يك ايده بد است ، زيرا هر سال بايد يك رابطه جديد ايجاد كنيم، و همچنين بايد پرسش هاي جديدي براي هر سال بنويسيم تا هر رابطه جديد را در نظر بگيريم. همچنين از آنجا كه پرسش ها بايد به رابطه هاي بيشتري مربوط شوند پيچيده تر هستند.
راه ديگر براي ارائه همان اطلاعات داشتن يك رابطه واحد Company-year است. دراينجا تنها وابستگی هاي عملیاتی از employee-id به ديگر صفات است، و باز هم رابطه در BCNF است. اين طرح نيز بد است زيرا مشكلاتي مشابه طرح قبلي دارد – از جمله بايد الگوي رابطه اي را اصلاح كرده وپرسش هاي جديدي براي هرسال بنويسيم .پرسش ها نيز پيچيده تر هستند زيرا به خواص بيشتري مربوط مشود.
چنين ارائه هايي مانند رابطه Company-year بايك ستون براي هرمقدار از يك صفت crosstabs نام دارد. كه بطور گسترده در spreadsheet ها و گزارشات وابزارهاي تحليل داده استفاده مي شود. از آنجا كه چنين ارائه هايي براي نمايش دادن به مصرف كنندگان مفيد است به دليلي كه اكنون ذكرشد درطرح هاي پايگاه داده مطلوب نيستند. بسط SQL براي برگرداندن اطلاعات ازيك ارائه رابطه هاي نرمال به يك crosstabs  براي نمايش دادن پيشنهاد مي شود.
7-9 مدل سازي داده هاي موقتي
فرض كنيد داده هايي رادر بانك بدست مي آوريم كه نه تنها آدرس هرمشتري را نشان مي دهد بلكه تمام آدرس هاي قبلي راكه بانك ازآنها مطلع است را داراست. ممكن است چنين سوالي را بپرسيم که تمامي مشترياني راكه درسال 1981 در princeton  زندگي مي كردند پيداكن. دراينجا ممكن است چندين آدرس براي مشتريان داشته باشيم هر آدرس تاريخ شروع و پاياني داردكه نشاندهنده زمان سكونت مشتري در آن آدرس است. يك مقدار براي زمان پايان مثلا null يك مقدار براي آينده مانند 9999-12-31 مي تواند مورداستفاده قرارگيرد تا نشان دهدكه مشتري هنوز درآن آدرس سكونت دارد. بطوركل داده موقتي        داده هايي هستندكه داراي يك فاصله زماني مربوط هستند كه درآن فاصله معتبر هستند. از اصطلاح      snap shot به معني مقدار داده درنقطه اي مشخص از زمان استفاده مي كنيم.
مدل سازي داده هاي موقتي به چند دليل مشكلي سخت است. مثلا فرض كنيد يك موجوديت customer داريم كه مي خواهيم يك آدرس كه با زمان تغيير مي كند باآن داشته باشيم براي اضافه كردن اطلاعات موقتي به يك آدرس ويك آدرس ،بايد يك خاصيت چند مقداري ايجاد كنيم . كه هريك از  مقدار هاي آن يك مقدار مركب از يك آدرس ويك فاصله زماني است علاوه بر مقدار هاي خاصيت تغيير زماني خود موجوديت ها نيز ممكن است اعتبارزماني داشته باشند بعنوان مثال رابطه بين يك مشتري ويك حساب زماني ثبت شود كه مشتري صاحب حساب مي شود . بنابراين بايد فاصله زماني معتبر را به مقدار هاي خاصيت موجوديت ها وروابط اضافه كنيم. اضافه كردن چنين جزئياتي به يك دياگرام E-R ، ايجاد آن ودرك آن را بسيار مشكل مي سازد. چندين پيشهاد براي بسط E-R وجود دارد تا به شكلي ساده مشخص كندكه يك خاصيت يا رابطه بازمان تغيير مي كند اماروش استاندارد قابل قبولي وجود ندارد.
هنگاميكه مقدار هاي داده رادرطول زمان دنبال مي كنيم وابستگي هاي عملیاتی كه فرض كرديم وجود دارد مانند
customer-id-> customer-street, customer-city
ممكن است ديگر وجود نداشته باشند درعوض محدوديت زير وجود دارد:
يك customer-id براي هر زمان t داده شده تنها يك مقدار customer-street دارد.
وابستگي هاي عملیاتی كه در نقطه زمان مشخص وجود دارند وابستگي هاي عملیاتی موقت نام دارند. يك وابسته عملیاتی موقت X -> Y دريك الگوي رابطه اي R وجوددارد اگر براي تمامي نمونه هاي قانوني r از R ، تمامی snap shot های r برای وابستگي عملیاتی X-> Y  مطلوب باشند.
مي توانيم تئوري طرح پايگاه داده رابطه اي راگسترش دهيم و وابستگي هاي عملیاتی موقتي رادرنظر بگيريم ولي بحث درمورد وابستگي هاي عملیاتی منظم به اندازه كافي مشكل بوده و تعداد بسيار كمي از طراحان آمادگي كاركردن باوابستگي هاي عملیاتی موقتي را دارند.
عملاً طراحان پايگاه داده  به روش هاي ساده تري براي طراحي پايگاه داده موقت روي مي آورند يك روش متداول طراحي پايگاه داده دست نخورده (كه شامل طرح  E-R  وطرح  رابطه اي است) بدون درنظر گرفتن تغييرات موقت (فقط يك snapshot درنظر گرفته شود) است. سپس طراح روابط مختلف رامطالعه كرده وتصميم مي گيرد كه كدام روابط نيازمند تغيير موقت است .
مرحله بعد اضافه كردن اعتبار زماني به هريك از رابطه هاست، كه بوسيله اضافه كردن تاريخ شروع و پايان بعنوان صفات مي باشد بطورمثال فرض كنيد يك رابطه course(course-id,course-little) داريم كه يك  courselittle را با هر course که با یک course-id تعريف مي شود مربوط مي سازد عنوان course ممكن است باگذشت زمان تغييركندكه مي تواند بايك range زماني معتبر بكار رود الگوي حاصله اينگونه است:
course(course-id, course-title, start,end)
يك نمونه ازاين رابطه ممكن است به دونوع ضبط شده باشد
(CS101,''INTRODUCTION TO C'', 1985-01-01,2000-12-31)
(CS101,''INTRODUCTION TO PROGRAMING'', 2001-01-01,9999-12-31)
اگر رابطه باتغييرCOURSE  به Introduction to java  جديد شود، زمان 9999-12-31 به زمانيكه در مقدار قبلي (introduction to c) معتبر است تبديل مي شود ويك چندگانه جديد اضافه مي شودكه شامل عنوان جديد (introduction to java) بايك زمان شروع مناسب است.
اگر رابطه ديگري يك كليد خارجي داشته باشدكه به يك رابطه موقت برگردد، طراح پايگاه داده مجبوراست كه تصميم گيرد آيا اين ارجاع مربوط به نسخه فعلي داده است يا مربوط به داده ايي از يك نقطه زماني مشخص است بعنوان مثال رابطه ای که اتاق تحویلی فعلی برای هر course که موقتاً به مقدار هر course-id اشاره داردرا ذخیره می کند. به عبارت ديگر ثبتي درنسخه يك دانش آموز شده است مربوط به course title درزماني است كه دانش آموز course را برداشته است دراين مورد اخير رابطه ارجاعي بايداطلاعات زمان را نيز ضبط كند تايك رکورد  به خصوص از رابطه course تشخيص داده شود .
كليد اوليه اصلي براي يك رابطه موقت ديگر يك چندگانه شناخته نمي شود براي حل اين مشكل   مي توانيم خاصيت زمان شروع و پايان را به كليد اوليه اضافه كنيم هرچند بازهم مشكلاتي باقي مي ماند:
ممكن است ذخيره داده ها همراه با فواصلي باشدكه هم پوشاني داشته باشند كه دراين حالت محدوديت كليد اوليه بکار گرفته نمی شود. اگر اين سيستم يك نوع valid time بومي را پشتیبانی كند اينگونه فواصل زماني هم پوشاني شده قابل تشخيص واجتناب هستند.
براي تعيين يك كليد خارجي كه به چنين رابطه اي برمي گردد، چند گانه هاي ارجاعي بايد شامل خاصيت زمان شروع وپايان به عنوان قسمتي از كليد خارجي اش باشد ومقدارها بايد مقدارهاي چند گانه ارجاعي match باشد. به علاوه، اگر چند گانه ارجاعي جديد شده است (وزمان پايان كه در آينده جديد مي شود) مورد جديد بايد درتمام چند گانه ارجاعي منتشر شود. اگر اين سيستم داده هاي موقت را در يك روش بهتر support كند ،چند گانه ارجاعي مي تواند به جاي يك branch زماني يك نقطه زماني تشكيل شود. به عنوان مثال يك رونوشت ثبتي ممكن است يك course-id ويك زمان (مثلا تاريخ شروع ترم) را تعيين كند كه براي تشخيص يك ثبت صحيح دررابطه course كافي است. 
 مثلا درپايگاه داده بانك مان، مي توانيم از طرحي كه ايجاد كرديم استفاده كنيم، طرحي كه تغييرات موقت رامشخص مي كند وهمچنين اطلاعات رايج راذخيره نمايد. همه اطلاعات تاريخي به روابط تاريخي منتقل مي شوند. بنابراين رابطه مشتري ممكن است تنها ذخيره آدرس مشخص باشد درحاليكه رابطه تاريخ-مشتري ممكن است شامل همه صفتهاي مشتري به علاوه صفتهاي زمان شروع وپايان باشد. اگرچه هر روش معمولي رابراي داده موقت آماده نمي كنيم اما در مورد آانها بحث مي كنيم ومثال هايي كه بتواند به شما در مورد طرح پايگاه داده وثبت داده موقت كمك كند ارائه مي دهيم. 


7-10 خلاصه  
اشكالات طرح پايگاه داده و اينكه چطور طرح الگوي پايگاه داده به طور خود كار از اين اشكالات جلوگيري مي كند را نشان داديم. اين اشكالات شامل اطلاعات تكرار شده و ضعف بعضي اطلاعات ارائه شده بود .
پيشرفت طرح پایگاه داده رابطه ای از طرح E-R وقتي الگويي به شكل صحيح تركيب شده و زمانيكه يك الگو بايد تجزيه شود را نشان داديم. همه تجزیه های معتبر باید بی عیب باشند.
فرض حوزه های اتمی و شکل اول نرمال را شرح دادیم.
مفهوم وابستگي عملیاتی و استفاده از دو شكل نرمالBoyce-codd ,  وشكل (BCNF) وسومين شكل نرمال 3NF را معرفي كرديم.
اگر تجزیه حافظ وابستگی است یک پایگاه داده را به روز کرده، همه وابستگی های عملیاتی می توانند از روابط جداگانه تصدیق شوند. بدون آنکه یک الحاق رابطه در تجزیه محاسبه شود.
دلايل منطقي وابستگي هاي عملیاتی را نشان داديم . همچنين تعريف پوشش متداول را ارائه داديم. همچنین تعریف پوشش استاندارد را بیان کردیم ،که یک مجموعه کمینه از وابستگی عملیاتی مشابه است برای یک مجموعه وابستگی عملیاتی مفروض.
الگوريتمي براي تجزيه رابطه به BCNF را بيان كرديم. روابطي براي اينكه تجزيه BCNF حافظ وابستگي نيست وجود دارد.
پوشش متداول استفاده شده در تجزيه رابطه 3NF را ارائه كرديم. رابطه ها در3NF  ممكن است داراي افزايش باشد اما هميشه تجزيه حافظ وابستگي به 3NF  وجود دارد. 
وابستگي هاي چند مقداري را ارائه داديم . چهارمين شكل نرمال 4NF با وابستگي هاي چند مقداري را نشان داديم . بخشC.1.1  بخش ضميمه جزئيات را در باره وابستگي هاي چند مقداري بيان مي كند.
شكل هاي نرمال ديگر، مانند PJNFوDKNF ، شكل هاي افزايشي نامحسوسي را حذف مي كند. كار با اين شكل ها سخت است و به ندرت از آن استفاده مي شود. در بخش ضميمه C جزئيات شكل هاي نرمال را بيان كرده است.
در یک مرور کلی از مطالب این بخش توجه کنید که ما توانستیم طراحی یک پایگاه داده رابطه ای را در یک رویکرد سخت با یک قالب بر پایه ریاضی بیان کنیم. این مهم ترین مزیت مدل رابطه E-R در مقابل سایر مدل هاست که که مطالعه کرده ایم.
 

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

HyperLink

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