Theory
નિયમો ની નીચેનો નિયમ
પાછલા lesson માં તમે કેમ normalization મહત્વની છે એ અનુભવ્યું. પણ એને ખરેખર કરવા, સાચી રીતે વહેંચવા, તમને એક ચોક્કસ idea જોઈએ: કયો column કયો નક્કી કરે છે.
જો તમે એક student નો roll number જાણો છો, તમે એનું name જાણો છો, roll number name ને determine કરે છે. આ એક functional dependency છે, અને દરેક normalization નિયમ એમને ઓળખવા પર બનેલો છે.
એક ચાલાક પ્રકાર પણ છે, transitive dependency, જે છુપી redundancy ઊભી કરે છે, અને એક નાની નિયમ-પુસ્તિકા, Armstrong's axioms, એમના વિશે વિચારવા. આ lesson normal forms ની પાછળની machinery છે.
Theory
એક વસ્તુ જાણવી તમને બીજી બતાવે છે
મને તમારો PIN code કહો અને હું તમને તમારું city કહી શકું, pincode city ને determine કરે છે (એક pincode, એક city). પણ મને તમારું city કહો અને હું તમારો pincode ન કહી શકું (એક city ના ઘણા). તો dependency ની એક દિશા છે: pincode city ને determine કરે છે, ઉલટું નહીં. Functional dependency બરાબર આ છે: ડાબી બાજુની value જાણવી તમને જમણી બાજુ બરાબર એક value બતાવે છે.
Theory
Functional dependency, ઔપચારિક રીતે
એક functional dependency ને X to Y લખાય છે, 'X, Y ને determine કરે છે' વંચાય છે: X ની દરેક value માટે બરાબર એક value of Y હોય છે.
roll_no to name (roll number જાણવું એક name આપે છે)
X એ determinant છે (નક્કી કરતી બાજુ). એક primary key નો આખો હેતુ એ છે કે એ પોતાની row ના દરેક બીજા column ને determine કરે છે.
એક partial dependency ત્યારે છે જ્યારે એક column ફક્ત એક composite key ના ભાગ પર નિર્ભર હોય, એક સમસ્યા જેને 2NF ઠીક કરશે. દિશા સાચી કરવી એ જ બધું છે: roll_no to name, ક્યારેય name to roll_no નહીં (names દોહરાય છે).
Theory
Transitive dependency: છુપી શૃંખલા
એક transitive dependency એ એક non-key attribute દ્વારા એક શૃંખલા છે:
X to Y અને Y to Z, તો X to Z પરોક્ષ રીતે
Meera ના orders માં ઉદાહરણ: order_id to customer_id (દરેક order નો એક customer) અને customer_id to customer_city (દરેક customer નું એક city). તો order_id to customer_city transitively, city order પર ફક્ત customer ના દ્વારા નિર્ભર છે.
આ ખરાબ છે: city દરેક order પર redundantly store થાય છે. Third normal form (3NF) બરાબર transitive dependencies કાઢવા માટે મોજૂદ છે.
Quiz
એક table માં: roll_no to department, અને department to hod (head of department). કઈ dependency roll_no ને hod સાથે જોડે છે?
- Transitive dependency, roll_no, hod ને ફક્ત department ના THROUGH determine કરે છે
- કોઈ સમસ્યા વગર એક સીધી functional dependency
- એક composite key પર એક partial dependency
- કોઈ dependency જ નહીં
Show the answer
Transitive dependency, roll_no, hod ને ફક્ત department ના THROUGH determine કરે છે
roll_no, department ને determine કરે છે, અને department, hod ને determine કરે છે, તો roll_no, hod ને પરોક્ષ રીતે, non-key attribute department ના દ્વારા determine કરે છે: એક transitive dependency. આ HOD ને department ના દરેક student માટે redundantly store કરાવે છે. 3NF એને department અને એના HOD ને એમના ખુદના table માં વહેંચીને કાઢે છે. A to B to C શૃંખલા ઓળખવી એ 3NF સવાલોનું મૂળ કૌશલ્ય છે.
Think first
Armstrong's ત્રણ axioms
Armstrong's axioms એ dependencies વિશે વિચારવાની નિયમ-પુસ્તિકા છે. ત્રણ પ્રાથમિક છે Reflexivity, Augmentation, અને Transitivity. શું તમે અંદાજ લગાવી શકો કે Transitivity શું કહે છે, એ જોતાં કે તમે એને હમણાં ઉપર વાપર્યું?
Show the answer
Transitivity: જો X to Y અને Y to Z, તો X to Z, બરાબર roll_no to department to hod શૃંખલા. બાકીના બે: Reflexivity (એક set પોતાના કોઈ પણ subset ને determine કરે છે, તુચ્છ રીતે, જો Y, X નો ભાગ છે તો X to Y) અને Augmentation (જો X to Y, તો તમે બંને બાજુ એ જ column ઉમેરી શકો: XZ to YZ). સાથે આ ત્રણ (વત્તા union અને decomposition જેવા derived નિયમો) sound અને complete છે: એ દરેક valid functional dependency કાઢી શકે છે. એ normalization ની પાછળનું ઔપચારિક engine છે.
Watch out
Marks ક્યાં કપાય છે
FD ની દિશા ખોટી કરવી: X to Y નો અર્થ X, Y ને determine કરે છે (determinant ડાબી બાજુ છે). transitive (X to Y to Z એક non-key attribute ના દ્વારા) ને એક સાદી dependency સાથે ભેળવવી, transitive એ ખાસ શૃંખલા છે જે 3NF કાઢે છે. અને જ્યારે પૂછાય, Armstrong's ત્રણ પ્રાથમિક axioms નામ આપો: reflexivity, augmentation, transitivity. એમને ભેળવવા, કે એક dependency નો arrow ઉલટાવવો, એ જગ્યા છે જ્યાં marks છાનેમાને ગાયબ થાય છે.
Theory
હવે normal forms સમજાય છે
તમે સંપૂર્ણપણે સજ્જ છો. Partial dependency એ 2NF નો દુશ્મન છે; transitive dependency એ 3NF નો દુશ્મન છે; અને તમે જે પણ split કરો છો એ એક functional dependency થી justified થાય છે. આગળનો lesson 1NF થી BCNF સુધી ચાલે છે, અને તમે દરેક form ને એક ખાસ પ્રકારની ખરાબ dependency કાઢતું જોશો જેને તમે હવે ઓળખો છો. આ theory એ કારણ છે કે normal forms આડેધડ નથી. આગળ: 1NF, 2NF, 3NF, BCNF.
Summary
Key takeaways
- એક functional dependency X to Y નો અર્થ X, Y ને determine કરે છે (દરેક X માટે એક Y); X એ determinant છે, ડાબી બાજુ.
- Primary key પોતાની row ના દરેક બીજા column ને functionally determine કરે છે.
- Partial dependency: એક column ફક્ત એક composite key ના ભાગ પર નિર્ભર (2NF નું નિશાન).
- Transitive dependency: X to Y to Z એક non-key attribute ના દ્વારા, તો X to Z પરોક્ષ (3NF નું નિશાન).
- Armstrong's axioms (reflexivity, augmentation, transitivity) FDs કાઢવાની sound, complete નિયમ-પુસ્તિકા છે.
- યાદ રાખવાની યુક્તિ: pincode, city ને determine કરે છે (એક દિશા); A to B to C છુપી શૃંખલા પર નજર રાખો.