ایک ڈیٹا بیس میں ایک سے زیادہ تعلقات ایک ایسا واقعہ ہوتا ہے جب ٹیبل اے میں ہر ریکارڈ کو ٹیبل بی میں بہت سے منسلک ریکارڈ مل سکتا ہے، لیکن ٹیبل بی میں ہر ریکارڈ میں ٹیبل میں صرف ایک ہی ریکارڈ ہوسکتا ہے. A میں ایک سے زیادہ تعلقات ایک ڈیٹا بیس سب سے زیادہ عام رشتہ دار ڈیٹا بیس ڈیزائن ہے اور اچھا ڈیزائن کے دل میں ہے.
اس استاد اور نصاب کے درمیان تعلقات پر غور کریں. ایک استاد ایک سے زیادہ کورس سکھ سکتا ہے، لیکن کورس کے استاد کے ساتھ ہی تعلق نہیں ہوگا.
لہذا، اساتذہ کی میز میں ہر ریکارڈ کے لئے، کورسز کی میز میں بہت سے ریکارڈ ہوسکتے ہیں. یہ ایک سے زیادہ تعلقات ہے: ایک استاد متعدد نصاب میں.
ایک سے زیادہ تعلقات قائم کرنا اہم کیوں ہے
ایک سے زیادہ تعلقات کی نمائندگی کرنے کے لئے، آپ کو کم سے کم دو میزیں کی ضرورت ہے. چلو کیوں دیکھتے ہیں.
شاید ہم نے ایک ٹیبل تیار کیا جس میں ہم نام اور نصاب کو پڑھ کر ریکارڈ کرنا چاہتے ہیں. ہم اس طرح اس طرح ڈیزائن کر سکتے ہیں:
| ٹیچر_ڈ | ٹیچر کا نام | کورس |
|---|---|---|
| ٹیچر_001 | کارن | حیاتیات |
| ٹیچر_002 | ویرونیکا | ریاضی |
| ٹیچر_003 | جارج | انگریزی |
کیا کارمین دو یا زیادہ کورسز سکھاتا ہے؟ ہمارے پاس اس ڈیزائن کے ساتھ دو اختیارات ہیں. ہم صرف کارمین کے موجودہ ریکارڈ میں شامل کر سکتے ہیں، اس طرح:
| ٹیچر_ڈ | استاد_ نام | کورس |
|---|---|---|
| ٹیچر_001 | کارن | حیاتیات، ریاضی |
| ٹیچر_002 | ویرونیکا | ریاضی |
| ٹیچر_003 | جارج | انگریزی |
تاہم، مندرجہ بالا ڈیزائن ناقابل یقین ہے اور اعداد و شمار داخل کرنے، ترمیم یا خارج کرنے کی کوشش کرتے وقت بعد میں مسائل پیدا ہوسکتا ہے.
ڈیٹا کو تلاش کرنا مشکل ہے. یہ ڈیزائن ڈیٹا بیس معمولی، پہلے عمومی فارم (1 این ایف) کے پہلے اصول کی خلاف ورزی کرتا ہے، جس میں یہ بتاتا ہے کہ ہر ٹیبل سیل میں اعداد و شمار کا واحد، ڈسکوک ٹکڑا ہونا چاہئے.
ایک اور ڈیزائن متبادل صرف کارمین کے لئے دوسرا ریکارڈ شامل کرنے کے لئے ہو سکتا ہے:
| استاد_ID | استاد_ نام | کورس |
|---|---|---|
| ٹیچر_001 | کارن | حیاتیات |
| ٹیچر_001 | کارن | ریاضی |
| ٹیچر_002 | ویرونیکا | ریاضی |
| ٹیچر_003 | جارج | انگریزی |
یہ 1NF کی پیروی کرتا ہے لیکن اب بھی غریب ڈیٹا بیس کے ڈیزائن ہے کیونکہ یہ بے شمار تعارف متعارف کرایا ہے اور غیر ضروری طور پر بہت بڑے ڈیٹا بیس کو بلا سکتا ہے. مزید اہم بات، اعداد و شمار متغیر بن سکتا ہے. مثال کے طور پر، کیا کارمین کا نام بدل گیا ہے؟ اعداد و شمار کے ساتھ کسی کو کام کرنا اس کے نام کو ایک ریکارڈ میں اپ ڈیٹ کر سکتا ہے اور دوسرا ریکارڈ میں اسے اپ ڈیٹ کرنے میں ناکام ہے. یہ ڈیزائن دوسرا عام فارم (2 این ایف) کی خلاف ورزی کرتا ہے، جو 1 این ایف کی پیروی کرتی ہے اور ڈیٹا کے سبسبلوں کو الگ الگ میزوں میں الگ الگ کرکے ان کے درمیان تعلقات پیدا کرنے سے متعدد ریکارڈوں کی بے حد سے بچنے کی بھی ضرورت ہوتی ہے.
ایک سے زیادہ تعلقات کے ساتھ ایک ڈیٹا بیس کو کیسے ڈیزائن کریں
اساتذہ اور نصاب کے ٹیبل میں ایک سے زیادہ تعلقات کو نافذ کرنے کے لئے، ہم میزیں دو میں تقسیم کرتے ہیں اور انہیں غیر ملکی کلید کا استعمال کرتے ہوئے لنک کرتے ہیں.
یہاں، ہم اساتذہ کی میز میں کورس کالم کو ہٹا دیا ہے:
| استاد_ID | استاد_ نام |
|---|---|
| ٹیچر_001 | کارن |
| ٹیچر_002 | ویرونیکا |
| ٹیچر_003 | جارج |
اور یہاں کورسز کی میز ہے. نوٹ کریں کہ اس کی غیر ملکی کلید، ٹیچر_ID، اساتذہ کی میز میں ایک استاد کو ایک کورس سے متعلق ہے:
| کورس_ID | Course_Name | ٹیچر_ڈ |
|---|---|---|
| کورس_001 | حیاتیات | ٹیچر_001 |
| کورس_002 | ریاضی | ٹیچر_001 |
| کورس_003 | انگریزی | ٹیچر_003 |
ہم غیر ملکی کلیدی کا استعمال کرتے ہوئے اساتذہ اور نصاب کی میز کے درمیان تعلقات تیار کر چکے ہیں.
یہ ہمیں بتاتا ہے کہ حیاتیات اور ریاضی دونوں کارمین کی طرف سے سکھایا جاتا ہے اور جارج انگریزی کو سکھاتا ہے.
ہم دیکھ سکتے ہیں کہ یہ ڈیزائن کس طرح کسی بھی ممکنہ بغاوت سے بچتا ہے، انفرادی اساتذہ کو ایک سے زیادہ کورس سکھانے کی اجازت دیتا ہے، اور ایک سے زیادہ تعلقات کو لاگو کرتی ہے.
ڈیٹا بیس بھی ایک سے تعلق رکھنے اور ایک سے زیادہ سے زیادہ تعلقات پر عمل درآمد کر سکتے ہیں.
