Candidate key — relationdagi har tupleni noyob aniqlaydigan va ortiqcha atributga ega bo‘lmagan minimal atributlar to‘plami. Relationda bir nechta candidate key bo‘lishi mumkin; ulardan biri primary key sifatida tanlanadi.
Noyoblik va minimallik
Superkey rowni noyob aniqlaydi, ammo ortiqcha atribut saqlashi mumkin. Schema testi normal qiymat bilan birga NULL, duplicate va concurrent amalni qamraydi. Candidate keydan bir atribut olib tashlansa uniqueness yo‘qoladi. Bu qoida database engine tomonidan barcha yozuvchi clientlarga bir xil qo‘llanadi. Noyoblik faqat hozirgi sample data emas, biznes qoidasiga asoslanadi. Aniq semantika SQL mahsuloti, collation va transaction rejimiga bog‘liq.
Primary va alternate key
Tanlangan candidate key primary key bo‘ladi. Bu qoida database engine tomonidan barcha yozuvchi clientlarga bir xil qo‘llanadi. Qolganlari alternate key sifatida unique constraint bilan saqlanadi. Aniq semantika SQL mahsuloti, collation va transaction rejimiga bog‘liq. Surrogate key natural candidate keylarni constraint bilan almashtirib yubormasligi kerak. Schema testi normal qiymat bilan birga NULL, duplicate va concurrent amalni qamraydi.
Composite key
Composite candidate key bir nechta atribut kombinatsiyasidan tuziladi. Aniq semantika SQL mahsuloti, collation va transaction rejimiga bog‘liq. U foreign keylarda keng va join indexlarda qimmat bo‘lishi mumkin. Schema testi normal qiymat bilan birga NULL, duplicate va concurrent amalni qamraydi. NULLga ruxsat candidate key semantikasini zaiflashtiradi. Bu qoida database engine tomonidan barcha yozuvchi clientlarga bir xil qo‘llanadi.
Schema evolyutsiyasi
Biznes identifier qayta ishlatilishi yoki formatini o‘zgartirishi mumkin. Schema testi normal qiymat bilan birga NULL, duplicate va concurrent amalni qamraydi. Key stability migration va external reference uchun muhim. Bu qoida database engine tomonidan barcha yozuvchi clientlarga bir xil qo‘llanadi. Yangi deduplication qoidasi mavjud duplicate rowsni oldindan tozalashni talab qiladi. Aniq semantika SQL mahsuloti, collation va transaction rejimiga bog‘liq.
Schema boshqaruvi
Candidate key faqat ORM validationida qoldirilmaydi; invariant mos bo‘lsa database constraint yoki transaction bilan yakuniy qatlamda himoyalanadi. Constraint nomi migration, monitoring va API error mappingda barqaror identifikator bo‘lib xizmat qiladi. Mavjud data yangi qoidaga o‘tishdan oldin alohida audit qilinadi.
Katta jadvaldagi validation lock, IO va replication lagga ta’sir qilishi mumkin, shuning uchun bosqichli rollout tanlanadi. Failure test concurrent writerlar va rollbackni qamraydi. Candidate key buzilishi logda sensitive qiymatni ochmasdan, table, constraint va operation konteksti bilan qayd etiladi.
Chekka holatlar va dalillar
Security reviewda noyoblik va minimallik bilan primary va alternate key bir xil natija deb qaralmaydi. Bir qatlam muvaffaqiyatli ko‘rinsa ham keyingi qatlamdagi mapping, policy yoki data holati umumiy xizmatni buzishi mumkin. Shu sabab input, oraliq qaror va yakuniy output alohida log yoki metric bilan kuzatiladi. Bo‘sh qiymat, limitga yaqin hajm, duplicate operation, kechikkan javob va qisman nosoz dependency maxsus testlarda qamrab olinadi.
Candidate key uchun composite key hamda schema evolyutsiyasi bo‘yicha kutilgan invariantlar yoziladi. Primary key, Alternate key, Superkey va Natural key bilan integratsiya configuration yoki schema yangilanganda qayta tekshiriladi. Normal trafficdagi muvaffaqiyat recovery tayyorligini isbotlamaydi; rollback, rotation yoki rebuild amalda bajarilib ko‘riladi. Natija owner, versiya va source position bilan saqlansa, keyingi incidentda sababni taxmin bilan emas, tekshirilgan dalil orqali aniqlash mumkin.
Bog‘liq tushunchalar
Primary key, Alternate key, Superkey, Natural key, Surrogate key, Unique constraint, Composite key, Functional dependency