Theory
Flat File ની અંધાધૂંધીનું જંગલરાજ
તમારા Semester 1 ના C programming labs માં, જો તમારે student ની વિગતો સંઘરવી હોય, તમે એમને comma થી છૂટી પડેલી values વાપરીને એક પાયાની text file (students.txt) માં લખતા. પણ જો તમારે માળખું બદલવું હોય તો શું થતું, ધારો કે બરાબર વચ્ચે એક 'Phone Number' column ઉમેરવો હોય? તમારો આખો C file વાંચવાનો code વેરવિખેર થઈ જાત કારણ કે એ બિલકુલ hardcode કરેલી અક્ષરની જગ્યાઓએ data ની અપેક્ષા રાખતો. એથી પણ ખરાબ, Notepad વાળું કોઈ પણ text file ખોલીને, તમારો program સંપૂર્ણપણે ટાળીને, data ની values બદલી શકતું, ચકાસણીની તપાસ તોડતાં. તો આપણે એવી ગાણિતિક રીતે સંરચિત સંગ્રહની system કેવી રીતે બનાવીએ કે ભૌતિક માળખું software તોડ્યા વગર બદલી શકાય, અને જ્યાં કોઈ પાછલા બારણાની છટકબારી ક્યારેય પરવાનગી ન પામે?
Theory
છૂટા કાગળનું ખોખું સામે આપોઆપ ચાલતું Smart Locker
એક પરંપરાગત file ની નોંધણીના ઓરડાને કલ્પો જ્યાં કાગળના records છૂટાં પૂંઠાનાં ખોખાંમાં નાખી દેવાય છે. જો કોઈને એક record જોઈએ, એ અંદર જાય છે, હાથે folders ફેંદે છે, અને છાનીછૂપી પેનથી આંકડા ફરીથી લખી શકે છે. આ એક બિન-relational database ની file નું માળખું છે. Dr. E.F. Codd ના નિયમો એ ઓરડાને એક અત્યંત સુરક્ષિત, આપોઆપ ચાલતી Smart Locker system માં બદલવા જેવું કામ કરે છે. તમે ક્યારેય જાતે એક ભૌતિક ખાનાને અડી શકતા નથી. તમારે એક આપોઆપ ચાલતા digital console ના interface સાથે વાત કરવી પડે. જો locker ની કંપની અંદરની છાજલીઓના આકાર ફરીથી ગોઠવે (ભૌતિક ફેરફાર) કે એક નવું user ની મંજૂરીનું સ્તર ઉમેરે (તાર્કિક ફેરફાર), તમારો console interface નો command બિલકુલ એનો એ જ રહે છે. Locker ખાતરી કરે છે કે data માત્ર એના અધિકૃત નિયંત્રણના કાચ દ્વારા જ મળી શકે.
Theory
પાયો: Rule 0 અને Relational ધોરણ
1970 માં, Dr. Edgar F. Codd (એક IBM વૈજ્ઞાનિક) એ relational model સ્થાપતું એક ક્રાંતિકારી ગાણિતિક પેપર પ્રકાશિત કર્યું. Software વેચનારાઓ પોતાનાં જૂનાં, અસ્તવ્યસ્ત file engines ને 'Relational' કહેતાં marketing નાં લેબલ ચોંટાડે એ અટકાવવા, એમણે 13 પાયાના કાયદા સ્થાપ્યા (0 થી 12 ક્રમાંકિત). Rule 0 (The Foundation Rule) કહે છે કે RDBMS હોવાનો દાવો કરતી કોઈ પણ system એ પોતાનાં databases સંપૂર્ણપણે એની relational ક્ષમતાઓ દ્વારા સંભાળી શકતી હોવી જોઈએ. જો એક database system તમને records લાવવા SQL માંથી બહાર નીકળીને નીચલા સ્તરની pointer file ની routines લખવા મજબૂર કરે, એ તરત RDBMS ની કસોટીમાં નાપાસ થાય છે.
At a glance
Table 1: Data ની રજૂઆત, પ્રાપ્યતા, અને એકસમાન schema માળખાને સંચાલિત કરતા Codd ના મુખ્ય નિયમો.
| નિયમનો ક્રમાંક અને નામ | મુખ્ય માળખાકીય મર્યાદા | Laboratory Systems માં એ કેમ Matter કરે છે |
|---|---|---|
| Rule 1: Information Rule | બધા data points, table નાં નામ અને columns સહિત, સ્પષ્ટપણે સપાટ tabular cells ની અંદર બેસવા જોઈએ. | છુપાયેલા બહુ-પરિમાણીય pointers કે query ન થઈ શકે એવી metadata arrays અટકાવે છે. |
| Rule 2: Guaranteed Access | દરેકે દરેક cell ની data value આ જોડીને અનન્ય રીતે પહોંચી શકાય એવી હોવી જોઈએ: Table Name + Primary Key + Column Name. | નીચલા સ્તરના ભૌતિક disk ના offsets કે હરોળના સરનામાના આંકડા પરની નિર્ભરતા દૂર કરે છે. |
| Rule 3: Systematic Null Treatment | System ખૂટતી કે લાગુ ન પડતી વિગતો 0 કે ખાલી strings થી અલગ એવા standard NULL નિશાનો વાપરીને વ્યવસ્થિત રીતે સંભાળવી જોઈએ. | સચોટ ગણતરીઓ ખાતરી કરે છે (દા.ત. scores ની સરેરાશ ખૂટતી પરીક્ષાઓને 0 marks ઉમેરવાને બદલે છોડી દે છે). |
| Rule 4: Dynamic Online Catalog | Database નાં સંરચનાત્મક schemas system tables ની અંદર સંઘરાવાં જોઈએ, standard SQL statements વાપરીને query થઈ શકે એવાં. | તમે students નાં નામ શોધવા વાપરો છો એ જ બિલકુલ SELECT statements વાપરીને ઉપલબ્ધ tables જુઓ છો. |
| Rule 11: Distribution Independence | User ના interface ની ભાષા data tables ભૌતિક રીતે અનેક વૈશ્વિક servers પર વહેંચાયેલાં હોય તો પણ સરળતાથી કામ કરવી જોઈએ. | એક database table સ્થાનિક drive પરથી cloud ના ભાગમાં ખસે તો પણ તમારી frontend queries તૂટતી નથી. |
Theory
ઊંડી ડૂબકી: Independence અને Non-Subversion ની ઢાલ
University નાં પ્રશ્નપત્રો વારંવાર Codd ની યાદીનાં બે અત્યંત તાંત્રિક લક્ષણો ચકાસે છે: Data Independence (Rules 8 અને 9) અને Non-Subversion Rule (Rule 12). Rule 8 (Physical Data Independence) ખાતરી આપે છે કે જો તમે database ની files એક જૂની ધીમી hard disk (HDD) પરથી એક ઝડપી Solid State Drive (SSD) પર ખસેડો, કે સંગ્રહના index નું સ્વરૂપ બદલો, તમારી application ના code ની queries અછૂતી રહે છે. Rule 9 (Logical Data Independence) ખાતરી કરે છે કે એક table ને બેમાં વહેંચવાથી (કે tables જોડવાથી) user ના programs સંપૂર્ણપણે ફરીથી લખવા ન પડે. છેલ્લે, Rule 12 (Non-subversion) સુરક્ષાના અમલદાર તરીકે કામ કરે છે.
Watch out
Rule 12: Subversion નો સુરક્ષા ખતરો
જો એક RDBMS પાસે ઉચ્ચ સ્તરની relational ભાષા (જેમ કે SQL) હોય પણ સાથે એક નીચલા સ્તરનું record-દર-record નું interface પણ આપે જે relational સુરક્ષા કે અખંડિતતાની મર્યાદાઓ ટાળે, તો એક દુષ્ટ program એ નીચલા સ્તરના દરવાજા વાપરીને ચકાસણીના triggers ચલાવ્યા વગર પગારનું સંતુલન બદલી શકે. Rule 12 આને સખ્તાઈથી મનાઈ કરે છે. નીચલા સ્તરના interface ને system ની મુખ્ય ચકાસણીની સીમાઓ તોડતાં રોકવું જ પડે.
Theory
Worked Example: Schema Metadata અને Integrity ની તપાસ
ચાલો એક વાસ્તવિક SQL system ના અમલ પર નજર કરીએ જે Rule 4 (Dynamic Online Catalog) અને Rule 10 (Integrity Independence) દર્શાવે છે. આપણે database ના પોતાના સંરચનાત્મક catalog ને query કરીશું જેથી દેખાય કે માળખાકીય metadata relational tables તરીકે સંભાળાય છે.
Practical
Querying the Authoritative Database Catalog
-- Step 1: Create a secure transaction table with an explicit primary key
CREATE TABLE student_ledger (
roll_no INT PRIMARY KEY,
student_name VARCHAR(50),
balance_amt DECIMAL(10,2)
);
-- Step 2: Query the Online Catalog (Rule 4) to verify columns exist relationally
SELECT table_name, column_name, data_type
FROM information_schema.columns
WHERE table_name = 'student_ledger';
-- Step 3: Test Systematic Null Treatment (Rule 3) and Integrity Constraints
INSERT INTO student_ledger (roll_no, student_name, balance_amt)
VALUES (101, 'Amit Sharma', NULL);Think first
Catalog અને Constraint ના પ્રતિભાવને ટ્રેસ કરો
જ્યારે Step 1 અને Step 2 ચાલે ત્યારે system ના catalog માં શું થાય છે? જો એક નીચલા સ્તરનું file લખનાર 101 નો બેવડો roll_no સીધો disk માં ધકેલવાનો પ્રયાસ કરે તો શું થાય?
Show the answer
Step 2 ચલાવવાથી 'roll_no', 'student_name', અને 'balance_amt' નું માળખું વર્ણવતો એક સાફ 3-હરોળનો dataset સીધો database ના આંતરિક tables માંથી પાછો મળે છે, Rule 4 દર્શાવતાં. જો એક અલગ tool બેવડી હરોળ 101 લખવાનો પ્રયાસ કરે, Rule 12 સાથે Rule 10 મળીને ખાતરી કરે છે કે database engine લખવાની કામગીરી આંતરી લે અને એને તરત એક integrity ના ઉલ્લંઘનની error સાથે રોકે, data ની સુસંગતતા બચાવતાં.
Quiz
Codd ના Rule 2 (Guaranteed Access Rule) પ્રમાણે, એક RDBMS માં કોઈ પણ ચોક્કસ પરમાણુ data value મેળવવાની ખાતરી કરવા કયા ત્રણ સંકેતાંકો જોડવા જ પડે?
- Database User ID, Row Number, અને Column Data Type.
- ભૌતિક Disk Sector નું સરનામું, Track Index, અને File Offset ની bytes.
- Table Name, હરોળની Primary Key Value, અને Column Name.
- IP Address, Port Number, અને Table Name નો ક્રમ.
Show the answer
Table Name, હરોળની Primary Key Value, અને Column Name.
Rule 2 ફરમાવે છે કે દરેકે દરેક scalar value ભૌતિક સરનામાની ચાલાકી વગર તાર્કિક રીતે મળી શકવી જોઈએ. Table Name, બિલકુલ હરોળનો ઓળખકર્તા (Primary Key), અને લક્ષ્ય લક્ષણ (Column Name) આપીને, તમે કોઈ પણ data point ને સંદેહ વગર અલગ પાડી શકો છો.
Quiz
Codd નો Rule 8 (Physical Data Independence) software developers ને કયો મુખ્ય ફાયદો ખાતરીથી આપે છે?
- એ users ને password ના credentials ટાઈપ કર્યા વગર database ના dashboard માં log in કરવા દે છે.
- એ ખાતરી આપે છે કે ભૌતિક સંગ્રહના માળખામાં થતા ફેરફારો (જેમ કે filesystems કે indexes બદલવા) માટે application ના program ની queries બદલવી પડતી નથી.
- એ tables ને strings આપોઆપ મોટા અક્ષરોના સ્વરૂપમાં ફેરવવા મજબૂર કરે છે.
- એ ખાતરી કરે છે કે એક database ની backup file માત્ર બહારના flash સંગ્રહના blocks પર જ સચવાય.
Show the answer
એ ખાતરી આપે છે કે ભૌતિક સંગ્રહના માળખામાં થતા ફેરફારો (જેમ કે filesystems કે indexes બદલવા) માટે application ના program ની queries બદલવી પડતી નથી.
Physical Data Independence data hard drive પર કેવી રીતે ભરાયેલો છે અને એનો તાર્કિક રીતે સંદર્ભ કેવી રીતે લેવાય છે એની વચ્ચે એક તીક્ષ્ણ સીમારેખા દોરે છે. આ administrators ને backend software ના code ની એક પણ લીટી ફરીથી લખ્યા વગર disk નો સંગ્રહ સુધારવા, index નાં માળખાં બનાવવા, કે hardware બદલવા દે છે.
Theory
Database ના નિયમોને Semester 3 અને ઉદ્યોગ સાથે જોડવા
Codd ના નિયમો સમજવાથી તમારો દૃષ્ટિકોણ પાયાના code ના loops લખવાથી ભરોસાપાત્ર distributed systems બનાવવા તરફ ખસે છે. Semester 3 Database Administration (BCA301) અને Cloud Analytics (BCA305) માં, જ્યારે તમે ઊંચી ઉપલબ્ધતાવાળા database clusters ગોઠવશો જે records ને અનેક data centers પર વહેંચે છે અને છતાં તમારી applications ને એક એકીકૃત interface દેખાડે છે, ત્યારે તમે Rule 11 (Distribution Independence) પર ખૂબ આધાર રાખશો.
Summary
Key takeaways
- Codd ના નિયમો એક વ્યાપક ચકાસણીયાદી આપે છે જે એક સાચા RDBMS ને પાયાના file managers થી અલગ પાડે છે.
- Rule 0 માંગે છે કે એક system બધી સંચાલનની ક્ષમતાઓ સખ્તાઈથી relational કામગીરી દ્વારા સંભાળે.
- Information અને Guaranteed Access ના નિયમો લાગુ કરે છે કે દરેક data value એક સાફ cell માં રહે, અનુમાનયોગ્ય સંકેતાંકો દ્વારા મળી શકે એવી.
- Data Independence ખાતરી આપે છે કે ભૌતિક માળખાં કે તાર્કિક જોડાણો બદલવાથી application ની queries તૂટશે નહીં.
- Rule 12 (Non-subversion) મુખ્ય database ની મર્યાદાઓ ટાળતા નીચલા સ્તરના પ્રવેશ પર પ્રતિબંધ મૂકીને સુરક્ષાની છટકબારીઓ બંધ કરે છે.
- Memory Hook: દરેક વસ્તુ સુધી tabular પ્રવેશ, કડક માળખાકીય સ્વતંત્રતા, અને પાછલા બારણાની સંપૂર્ણ શૂન્ય છટકબારી!