Theory
बुरे data को दरवाज़े पर रोकना
एक spreadsheet में, कोई भी एक negative price type कर सकता है, एक name ख़ाली छोड़ सकता है, या वही customer दो बार डाल सकता है। कुछ उन्हें नहीं रोकता, और Meera के totals चुपचाप गलत हो जाते हैं।
एक database इनकार करता है। आप उसे नियम देते हैं, जिन्हें constraints कहते हैं, और वह उन्हें हर एक insert पर लागू करता है। बुरा data सचमुच अंदर नहीं आ सकता।
यह पूरी 'databases spreadsheets को क्यों हराते हैं' कहानी का फल है, और यह Unit 3 वाली अमूर्त keys को असली, लागू की गई गारंटियों में बदल देता है। यह lesson database का प्रतिरक्षा तंत्र है।
Theory
एक checklist वाला security guard
data के दरवाज़े पर एक security guard की कल्पना कीजिए जिसके पास एक checklist है: 'Name भरा है? (NOT NULL) Price positive है? (CHECK) ID पहले से इस्तेमाल नहीं हुआ? (UNIQUE) कोई form नहीं? standard वाला इस्तेमाल कीजिए (DEFAULT)।' कोई भी जो एक check में विफल हो उसे दरवाज़े पर ही लौटा दिया जाता है, बुरा data कभी घुसता नहीं। एक spreadsheet का कोई guard नहीं; एक database का एक है जो कभी सोता नहीं और कभी अपवाद नहीं करता।
At a glance
Constraints
| Constraint | जो नियम लागू करता है | उदाहरण |
|---|---|---|
| NOT NULL | एक value होनी चाहिए | item NOT NULL |
| UNIQUE | कोई duplicates नहीं (null ठीक) | phone UNIQUE |
| CHECK | एक condition पूरी करनी चाहिए | CHECK (price > 0) |
| DEFAULT | ख़ाली होने पर auto-fill | qty DEFAULT 0 |
| PRIMARY KEY | Unique + NOT NULL (एक/table) | id PRIMARY KEY |
| FOREIGN KEY | दूसरी table की key से मेल | customer_id references Customer |
Practical
A table that defends itself
CREATE TABLE sales (
id INT PRIMARY KEY, -- unique + not null
item VARCHAR(30) NOT NULL, -- must be given
category VARCHAR(20) DEFAULT 'Misc',-- auto-fills
price INT CHECK (price > 0), -- no negatives
qty INT DEFAULT 0
);
-- This INSERT is REJECTED: price is negative
-- INSERT INTO sales VALUES (6, 'Salt', 'Grocery', -5, 10);
-- This one is accepted
INSERT INTO sales (id, item, price) VALUES (6, 'Salt', 12);
-- category becomes 'Misc', qty becomes 0 (defaults)This example runs in Gri-Learn on the web, where you can edit it and see the output.
Theory
Foreign keys और ON DELETE CASCADE
Unit 3 वाला FOREIGN KEY एक लागू नियम बन जाता है: एक order का customer_id एक असली customer से मेल खाना ही चाहिए, आप एक ऐसे customer के लिए order नहीं बना सकते जो मौजूद ही नहीं (referential integrity)।
पर तब क्या होता है जब Meera एक ऐसे customer को delete करती है जिसके orders हैं? ON DELETE CASCADE जवाब देता है: अपने-आप उस customer के orders भी delete कर दो, ताकि कोई अनाथ orders एक ग़ायब customer की ओर न इशारा करें। इसके बिना, database integrity बचाने को delete को रोक देगा। Cascade का मतलब 'बच्चों को माता-पिता के साथ delete करो'।
Quiz
Meera की table में price INT CHECK (price > 0) है। वह price -5 वाला एक item insert करने की कोशिश करती है। क्या होता है?
- Insert REJECT होता है; CHECK constraint negative prices मना करता है
- यह -5 के रूप में insert होता है; CHECK सिर्फ एक सुझाव है
- यह अपने-आप 0 के रूप में insert होता है
- पूरी table delete हो जाती है
Show the answer
Insert REJECT होता है; CHECK constraint negative prices मना करता है
एक CHECK constraint लागू होता है: price > 0 होना ही चाहिए, तो -5 insert करना reject होता है और बुरी row कभी अंदर नहीं आती। यह एक spreadsheet से मुख्य फ़र्क़ है, जो ख़ुशी-ख़ुशी -5 store कर लेता। Constraints गारंटियाँ हैं, सुझाव नहीं; DBMS किसी भी data से इनकार करता है जो उनका उल्लंघन करे। "CHECK क्या करता है?" एक मानक exam सवाल है।
Think first
orders वाले एक customer को delete कीजिए
Meera customer 101 को delete करती है, जिसके 5 orders हैं। orders table में customer_id एक FOREIGN KEY है। ON DELETE CASCADE के बिना क्या होता है, और उसके साथ क्या होता है?
Show the answer
CASCADE के बिना: delete रुक जाता है, database इनकार करता है, क्योंकि customer 101 को delete करना 5 अनाथ orders छोड़ देता जो एक ग़ैर-मौजूद customer की ओर इशारा करते (referential integrity का उल्लंघन)। ON DELETE CASCADE के साथ: customer 101 को delete करना अपने-आप उनके 5 orders भी delete कर देता है, साफ़-सुथरे, कोई अनाथ नहीं। Cascade delete को dependent rows तक 'बहने' देता है। यह एक पसंदीदा exam परिदृश्य है।
Watch out
Marks कहाँ कटते हैं
UNIQUE (कोई duplicates नहीं, null की इजाज़त, कई प्रति table) को PRIMARY KEY (unique + NOT NULL, प्रति table सिर्फ एक) से गड्डमड्ड करना। यह सोचना कि एक CHECK वैकल्पिक है, यह लागू होता है, उसका उल्लंघन करती insertions reject होती हैं। यह भूलना कि DEFAULT सिर्फ तब भरता है जब कोई value न दी जाए। और यह चूकना कि ON DELETE CASCADE क्या करता है (बच्चे auto-delete) बनाम default (delete रोकना)। ये constraint फ़र्क़ marks से भरे हुए हैं।
Theory
यही वजह है कि databases पर भरोसा होता है
Banks, railways और Aadhaar databases पर चलते हैं ठीक इसलिए कि constraints अमान्य data को असंभव बनाते हैं, कोई negative balances नहीं, कोई duplicate PANs नहीं, कोई अनाथ records नहीं। Unit 3 में आपने जो keys design कीं वे ये लागू नियम बन जाती हैं। दो lessons बचते हैं: functions जो rows को summarise करती हैं (aggregates) और values को transform करती हैं (scalars), फिर sequences और views subject ख़त्म करने को। आगे: aggregate functions।
Summary
Key takeaways
- Constraints वे नियम हैं जो DBMS हर insert पर लागू करता है; बुरा data दरवाज़े पर reject होता है।
- NOT NULL एक value माँगता है; UNIQUE duplicates मना करता है (null की इजाज़त); CHECK एक condition जाँचता है; DEFAULT auto-fill करता है।
- PRIMARY KEY = unique + NOT NULL, प्रति table एक; FOREIGN KEY दूसरी table की key तक referential integrity लागू करता है।
- ON DELETE CASCADE माता-पिता के delete होने पर child rows auto-delete करता है (वरना delete रुकता है)।
- यह लागू integrity ठीक वही है जो spreadsheets में नहीं होती।
- याद रखने का hook: एक checklist वाला security guard बुरे data को दरवाज़े पर लौटाता।