2-mavzu. Ma’lumotlar bazasida tashqi bog’lanish


Agar modifikatsiyalash bo'yicha buyruqni bajarsangiz, nima bo'ladi?


Download 198.12 Kb.
bet7/15
Sana29.03.2023
Hajmi198.12 Kb.
#1308553
1   2   3   4   5   6   7   8   9   10   ...   15
Bog'liq
2-mavzu. Ma’lumotlar bazasida tashqi bog’lanish va birlashmalar

Agar modifikatsiyalash bo'yicha buyruqni bajarsangiz, nima bo'ladi?


Kelinglar, bizning misol jadvallarimizda yaratilgan barcha chet el kalitlari quyidagicha e'lon qilinadi va chet el kalitlari cheklovlari bilan bajariladi: JADVALNI SATISH Sotuvchilar (snum integer NOT NULL PRIMARY KEY, sname char (10) NOT NULL, city char (10) , o'nlik kasr); JADVAL MUZALARINI CREATE (cnum integer NOT NULL PRIMARY KEY, cname char (10) NOT NULL, city char (10), rating integer, snum integer, FOREIGN KEY (snum) ADABIYOTLAR Sotuvchilar, UNIQUE (cnum, snum); JADVAL SIRALARINI TUZISH (
cnum integer NULL PRIMARY KEY emas, amt kasr, odate sana NULL EMAS, cnum integer
NULL snum integer NOT NULL EXITION KEY (cnum, snum) Adabiyotlar Mijozlar (cnum, snum);

Jadval tavsiflarini o'z ichiga oladi


Bunday ta'riflarning bir nechta atributlari haqida gapirish mumkin. Buyurtma jadvalidagi knum va snum maydonlarini bitta chet el kalitiga aylantirishga qaror qilganimizning sababi, buyurtmalardagi har bir mijoz uchun ushbu buyurtmani sotuvchi mijozlar jadvalida ko'rsatilgan bilan bir xil bo'lishiga kafolatdir. Bunday tashqi kalitni yaratish uchun biz UNIQUE jadval cheklovini xaridorlar jadvalining ikkita maydoniga joylashtirishimiz kerak bo'ladi, hatto jadvalning o'zi uchun kerak bo'lmasa ham. Ushbu jadvaldagi cnum maydoni BIRINChI KEY chekloviga ega ekan, u har qanday holatda ham noyob bo'ladi va shuning uchun boshqa maydon bilan knum maydonining yana bir kombinatsiyasini olish mumkin emas. Chet el kalitini shu tarzda yaratish ma'lumotlar bazasining yaxlitligini saqlaydi, garchi bu sizning ichki xatolaringiz bilan xalaqit berishga va shu xaridorga tayinlanganidan boshqa har qanday sotuvchiga qarz berishga xalaqit beradigan bo'lsa ham.
Ma'lumotlar bazasining yaxlitligini saqlash nuqtai nazaridan ichki uzilishlar (yoki istisnolar), albatta, istalmagan. Agar siz ularga ruxsat bersangiz va shu bilan birga ma'lumotlar bazangizning yaxlitligini saqlamoqchi bo'lsangiz, Buyurtma jadvalidagi snum va cnum maydonlarini navbati bilan Salespersons va Clients jadvallaridagi ushbu maydonlar uchun mustaqil tashqi kalit sifatida e'lon qilishingiz mumkin. Darhaqiqat, buyurtma jadvalidagi snum maydonlarini biz qilganimiz kabi ishlatish ixtiyoriy, garchi o'zgarish uchun buni qilish foydalidir. Mijozlar jadvalidagi, buyurtmalar jadvalidagi va mijozlar jadvalidagi xaridorlarning har bir buyurtmasini bog'laydigan cnum maydoni har doim ma'lum bo'lishi kerak (istisnolarga yo'l qo'ymaslik uchun) to'g'ri snum maydonini topish uchun. Bu shuni anglatadiki, biz biron bir ma'lumotni - qaysi mijoz qaysi sotuvchiga tayinlanganini - ikki marta yozib olamiz va har ikkala versiyaning mos kelishiga ishonch hosil qilish uchun qo'shimcha ishlarni bajarish kerak bo'ladi. Yuqorida aytib o'tilganidek, bizda tashqi kalit cheklovi bo'lmasa, bu vaziyat juda muammoli bo'ladi, chunki har bir buyurtma to'g'ri sotuvchining har bir sotuvga kredit berishini ta'minlash uchun (so'rov bilan birga) qo'lda tekshirilishi kerak. Ma'lumotlar bazangizda ushbu turdagi ma'lumotlarning ortiqcha bo'lishi denormalizatsiya deb ataladi, bu ideal munosabat bazasida keraksiz, garchi amalda uni hal qilish mumkin bo'lsa. Demoralizatsiya ba'zi so'rovlarni tezroq ishlashiga olib kelishi mumkin, chunki bitta jadvaldagi so'rov har doim qo'shilishdan ancha tezroq bo'ladi.

Download 198.12 Kb.

Do'stlaringiz bilan baham:
1   2   3   4   5   6   7   8   9   10   ...   15




Ma'lumotlar bazasi mualliflik huquqi bilan himoyalangan ©fayllar.org 2024
ma'muriyatiga murojaat qiling