Theory
एक order, या सौ?
Meera के design में एक Customer और एक Order है, 'देता है' से जुड़े। पर एक महत्वपूर्ण सवाल तय करता है कि tables असल में कैसे काम करती हैं: कितने? क्या एक customer एक order देता है, या कई?
उस 'कितने' को cardinality कहते हैं, और इसे सही करना एक ऐसे database, जो काम करता है, और एक ऐसे, जो data खोता है, के बीच का फ़र्क़ है। एक तरह की cardinality, many-to-many, इतनी माँग वाली है कि यह आपको एक अतिरिक्त table जोड़ने पर मजबूर करती है, ठीक वह सूझ जो Meera के पूरे design को समझाएगी। यह lesson relationships का 'कितने' है।
Theory
एक परिवार में connections गिनना
परिवार के रिश्ते सोचिए। एक व्यक्ति और उसका Aadhaar number: दोनों तरफ ठीक एक (one-to-one)। एक माँ और उसके बच्चे: एक माँ, कई बच्चे (one-to-many)। Students और वे subjects जो वे लेते हैं: हर student कई subjects लेता है, हर subject के कई students हैं (many-to-many)। आप cardinality को पहले से सहज-बोध से समझते हैं, यह बस गिनना है कि हर तरफ के कितने जुड़ते हैं।
At a glance
cardinalities
| Type | मतलब | उदाहरण |
|---|---|---|
| One-to-one (1:1) | हर तरफ, ज़्यादा से ज़्यादा एक | Person to Aadhaar |
| One-to-many (1:N) | एक कई से जुड़ता है | Customer to Orders |
| Many-to-one (N:1) | वही, कई वाली तरफ से देखा | Orders to Customer |
| Many-to-many (M:N) | हर तरफ कई से जुड़ता है | Students to Courses |
Theory
Many-to-many समस्या
One-to-one और one-to-many tables में साफ़-सुथरे बैठते हैं। पर many-to-many को सीधे दो tables में store नहीं किया जा सकता, आप links कहाँ रखेंगे? एक customer कई items ख़रीदता है और एक item कई customers द्वारा ख़रीदा जाता है; किसी table में एक list के लिए जगह नहीं।
इसका इलाज बीच में एक junction (linking) table है। एक दुकान के लिए, वह Orders table है: यह गंदे M:N (customers to items) को दो साफ़ one-to-many relationships में तोड़ता है (एक customer से कई orders, एक item कई orders में आता)। हर many-to-many एक बीच की table बन जाता है।
Quiz
एक college में, हर student कई courses में enrol करता है, और हर course के कई students हैं। यह कौन सी cardinality है, और इसे implement करने को क्या चाहिए?
- Many-to-many, एक junction/linking table की ज़रूरत
- One-to-many, सीधे दो tables में store होने लायक
- One-to-one, किसी अतिरिक्त table की ज़रूरत नहीं
- Many-to-one, बस एक foreign key
Show the answer
Many-to-many, एक junction/linking table की ज़रूरत
हर तरफ दूसरी के कई से जुड़ता है, तो यह many-to-many (M:N) है। यह सिर्फ Student और Course tables में नहीं रह सकता; इसे student-और-course की जोड़ियाँ रखने वाली एक junction table (एक Enrollment table) चाहिए, M:N को दो one-to-many relationships में बाँटती। 'Students और courses' THE textbook M:N उदाहरण है, और junction-table की ज़रूरत मुख्य exam बिंदु है।
Think first
Cardinality पहचानिए
Meera कहती है: 'मेरा हर order ठीक एक customer का है, पर एक customer के कई orders हो सकते हैं।' इसे CUSTOMER की तरफ से पढ़ते हुए, यह कौन सी cardinality है? और क्या इसे एक junction table चाहिए?
Show the answer
Customer की तरफ से यह one-to-many (1:N) है: एक customer, कई orders। (Order की तरफ से वही relationship many-to-one है, वही link, उल्टा नज़रिया।) इसे एक junction table नहीं चाहिए, one-to-many सीधे store होता है customer की key को हर order row में डालकर। सिर्फ many-to-many को अतिरिक्त बीच की table चाहिए। 1:N असली databases में सबसे आम relationship है।
Watch out
Marks कहाँ कटते हैं
यह छूटना कि many-to-many को एक junction table चाहिए, यहाँ का सबसे महत्वपूर्ण implementation तथ्य। one-to-many और many-to-one को गड्डमड्ड करना: वे उल्टे सिरों से देखा गया एक ही relationship हैं, अलग designs नहीं। और कमज़ोर उदाहरण देना, कुरकुरे classics इस्तेमाल कीजिए: person-Aadhaar (1:1), mother-children या customer-orders (1:N), students-courses (M:N)। Exams आपसे हर एक को नाम देने और एक उदाहरण देने दोनों को कहते हैं।
Theory
यह Meera के पूरे design को समझाता है
अब समझ आता है कि एक दुकान का database कभी सिर्फ 'customers और items' क्यों नहीं होता: इसे बीच में एक Orders table चाहिए, ठीक इसलिए क्योंकि customers-to-items many-to-many है। वह बीच की table वह जगह है जहाँ keys अपना काम करती हैं, जो अगले lessons का सेट है। Cardinality वह वजह है कि database designs में वे tables होती हैं जो होती हैं। आगे: एक entity को अपने दम पर टिकने के लिए क्या चाहिए, strong बनाम weak entities।
Summary
Key takeaways
- Cardinality = एक entity के कितने दूसरी से जुड़ते हैं।
- One-to-one (1:1): हर तरफ ज़्यादा से ज़्यादा एक (person to Aadhaar)।
- One-to-many (1:N): एक कई से जुड़ता है (customer to orders); सबसे आम; सीधे store होता है।
- Many-to-one वही 1:N relationship है दूसरी तरफ से देखा।
- Many-to-many (M:N): हर तरफ कई से जुड़ता है (students to courses); एक junction/linking table चाहिए।
- याद रखने का hook: person-Aadhaar (1:1), mother-children (1:N), students-courses (M:N)।