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 માં નથી હોતી.
- યાદ રાખવાની યુક્તિ: એક checklist વાળો security guard ખરાબ data ને દરવાજે પાછો વાળે.