ہم ڈیٹا بیس اور SQL زبان کا تجزیہ کرتے ہیں۔ (حصہ 5 - کنکشنز اور جوڑ) - "A سے Z تک جاوا پروجیکٹ"

جاوا پروجیکٹ بنانے کے سلسلے میں ایک مضمون (دیگر مواد کے لنکس آخر میں ہیں)۔ اس کا مقصد کلیدی ٹیکنالوجیز کا تجزیہ کرنا ہے، نتیجہ ٹیلی گرام بوٹ لکھنا ہے۔

• ڈیٹا بیس میں تعلقات کی اقسام
  • ایک سے کئی
  • ایک سے ایک (ایک سے ایک)
  • کئی سے کئی
• کنکشنز (جوائنز)
  • اندرونی شرکت
  • بائیں شمولیت
  • رائٹ جوائن
  • محفوظ جوائنز
• گھر کا کام

سب کو ہیلو، مستقبل کے سینئرز اور سافٹ ویئر کے سینئرز۔ جیسا کہ میں نے پچھلے حصے میں کہا تھا ( ہوم ​​ورک چیک کرنا )، آج نیا مواد آئے گا۔ ان لوگوں کے لیے جو خاص طور پر شوقین ہیں، میں نے ایک دلچسپ ہوم ورک اسائنمنٹ تیار کیا ہے تاکہ وہ لوگ جو پہلے سے ہی سب کچھ جانتے ہیں اور جو نہیں جانتے لیکن گوگل کرنا چاہتے ہیں وہ اس کی مشق کر سکتے ہیں اور اپنی صلاحیتوں کو جانچ سکتے ہیں۔ آج ہم کنکشن اور جوائن کی اقسام کے بارے میں بات کریں گے۔

ڈیٹا بیس میں تعلقات کی اقسام

یہ سمجھنے کے لیے کہ رشتے کیا ہیں، آپ کو یاد رکھنا ہوگا کہ غیر ملکی کلید کیا ہے۔ ان لوگوں کے لیے جو بھول گئے، سیریز کے آغاز میں خوش آمدید ۔

ایک سے کئی

آئیے ممالک اور شہروں کے ساتھ اپنی مثال کو یاد رکھیں۔ یہ واضح ہے کہ ایک شہر کا ایک ملک ہونا ضروری ہے۔ کسی ملک کو شہر سے کیسے جوڑا جائے؟ ہر شہر کے ساتھ اس ملک کا ایک منفرد شناخت کنندہ (ID) منسلک کرنا ضروری ہے جس سے اس کا تعلق ہے: ہم یہ پہلے ہی کر چکے ہیں۔ اسے کنکشن کی اقسام میں سے ایک کہا جاتا ہے - ایک سے کئی (انگریزی ورژن کو جاننا بھی اچھا ہوگا - ایک سے کئی)۔ بیان کرنے کے لیے، ہم کہہ سکتے ہیں: کئی شہر ایک ملک کے ہو سکتے ہیں۔ اس طرح آپ کو اسے یاد رکھنا چاہئے: ایک سے کئی رشتہ۔ اب تک یہ واضح ہے، ٹھیک ہے؟ اگر نہیں، تو یہاں انٹرنیٹ سے پہلی تصویر ہے: یہ ظاہر کرتا ہے کہ گاہکوں اور ان کے احکامات موجود ہیں. یہ سمجھ میں آتا ہے کہ ایک گاہک ایک سے زیادہ آرڈر دے سکتا ہے۔ ایک سے کئی ہے :) یا دوسری مثال: تین میزیں ہیں: پبلشر، مصنف اور کتاب۔ ہر وہ ناشر جو دیوالیہ نہیں ہونا چاہتا اور کامیاب ہونا چاہتا ہے اس کے ایک سے زیادہ مصنف ہیں، کیا آپ اتفاق نہیں کرتے؟ بدلے میں، ہر مصنف کی ایک سے زیادہ کتابیں ہو سکتی ہیں - اس میں بھی کوئی شک نہیں ہو سکتا۔ اور اس کا مطلب ہے، ایک بار پھر، ایک مصنف کا کئی کتابوں سے، ایک پبلشر کا کئی مصنفین سے تعلق ۔ اس کے علاوہ اور بھی بہت سی مثالیں دی جا سکتی ہیں۔ ابتدائی طور پر ادراک میں دشواری صرف خلاصہ سوچنا سیکھنے میں ہوسکتی ہے: میزوں اور ان کے تعامل کو باہر سے دیکھنا۔

ایک سے ایک (ایک سے ایک)

یہ ایک سے متعدد مواصلات کا ایک خاص معاملہ کہا جاسکتا ہے۔ ایسی صورتحال جس میں ایک ٹیبل میں ایک ریکارڈ دوسرے ٹیبل میں صرف ایک ریکارڈ سے متعلق ہے۔ زندگی سے کیا مثالیں ہو سکتی ہیں؟ اگر ہم تعدد ازدواج کو چھوڑ دیں تو ہم کہہ سکتے ہیں کہ میاں بیوی کے درمیان ون ٹو ون رشتہ ہے۔ اگرچہ ہم یہ کہتے ہیں کہ تعدد ازدواج کی اجازت ہے، تب بھی ہر بیوی کا صرف ایک شوہر ہو سکتا ہے۔ والدین کے بارے میں بھی یہی کہا جا سکتا ہے۔ ہر شخص کا صرف ایک حیاتیاتی باپ اور صرف ایک حیاتیاتی ماں ہو سکتی ہے۔ واضح ون ٹو ون رشتہ۔ جب میں یہ لکھ رہا تھا، میرے ذہن میں ایک خیال آیا: پھر کیوں ایک سے ایک رشتہ کو مختلف جدولوں میں دو ریکارڈوں میں تقسیم کیا جائے، اگر وہ پہلے سے ہی ون ٹو ون رشتہ رکھتے ہیں؟ میں خود اس کا جواب لے کر آیا ہوں۔ یہ ریکارڈ دوسرے طریقوں سے دوسرے ریکارڈ سے بھی منسلک ہو سکتے ہیں۔ میں کس بارے میں بات کر رہا ہوں؟ ملک اور صدر کے درمیان ون ٹو ون رابطوں کی ایک اور مثال ہے۔ کیا صدر کے بارے میں تمام اعداد و شمار کو "ملک" ٹیبل میں لکھنا ممکن ہے؟ ہاں، آپ کر سکتے ہیں، SQL ایک لفظ نہیں کہے گا۔ لیکن اگر آپ کو لگتا ہے کہ صدر بھی ایک شخص ہے... اور اس کی بیوی بھی ہو سکتی ہے (دوسرا ون ٹو ون رشتہ) اور بچے (دوسرا ون ٹو ون رشتہ) اور پھر پتہ چلا کہ ایسا ہو گا۔ ملک کو صدر کی اہلیہ اور بچوں سے جوڑنے کے لیے ضروری ہے۔ پاگل لگتا ہے، ٹھیک ہے؟ :D اس تعلق کے لیے اور بھی بہت سی مثالیں ہو سکتی ہیں۔ مزید برآں، ایسی صورت حال میں، آپ دونوں جدولوں میں ایک غیر ملکی کلید شامل کر سکتے ہیں، ایک سے کئی تعلق کے برعکس۔

کئی سے کئی

پہلے سے ہی نام کی بنیاد پر، آپ اندازہ لگا سکتے ہیں کہ ہم کیا بات کریں گے۔ اکثر زندگی میں، اور ہم اپنی زندگیوں کا پروگرام کرتے ہیں، ایسے حالات ہوتے ہیں جب مندرجہ بالا قسم کے کنکشن ہماری ضرورت کی چیزوں کو بیان کرنے کے لیے کافی نہیں ہوتے ہیں۔ ہم پبلشرز، کتابوں اور مصنفین کے بارے میں پہلے ہی بات کر چکے ہیں۔ یہاں بہت سارے کنکشن ہیں... ہر اشاعت میں کئی مصنفین ہو سکتے ہیں - ایک سے کئی کنکشن۔ ایک ہی وقت میں، ہر مصنف کے کئی پبلشرز ہو سکتے ہیں (کیوں نہیں، مصنف ایک جگہ شائع ہوا تھا، پیسے پر جھگڑا ہوا تھا، دوسرے پبلشنگ ہاؤس میں گیا تھا، مثال کے طور پر)۔ اور یہ ایک بار پھر ایک سے زیادہ رشتہ ہے۔ یا یہ: ہر مصنف کی کئی کتابیں ہو سکتی ہیں، لیکن ہر کتاب میں کئی مصنفین بھی ہو سکتے ہیں۔ ایک بار پھر، مصنف اور کتاب، کتاب اور مصنف کے درمیان ایک سے زیادہ رشتہ۔ اس مثال سے ہم ایک اور باضابطہ نتیجہ اخذ کر سکتے ہیں: یہ واضح تھا کہ ایس کیو ایل میں کنکشن کی پچھلی اقسام کو کیسے ترتیب دیا جائے: ہم صرف اس کی شناخت کو ان ریکارڈز میں منتقل کرتے ہیں، جن میں سے بہت سے ہیں، ٹھیک ہے؟ ایک ملک کئی شہروں کو اپنی شناخت غیر ملکی کلید کے طور پر دیتا ہے۔ کئی سے کئی رشتوں کا کیا کرنا ہے ؟ یہ طریقہ مناسب نہیں ہے۔ ہمیں ایک اور ٹیبل شامل کرنے کی ضرورت ہے جو دو ٹیبلز کو جوڑ دے گی۔ مثال کے طور پر، آئیے MySQL پر جائیں، ایک نیا ڈیٹا بیس manytomany بنائیں، دو ٹیبل بنائیں، مصنف اور کتاب، جس میں صرف نام اور ان کی ID ہوں گی: ڈیٹا بیس بنائیں manytomany؛ بہت سے استعمال کریں؛ ٹیبل مصنف بنائیں (ID INT AUTO_INCREMENT، نام VARCHAR(100)، بنیادی کلید (id)؛ ٹیبل بک بنائیں (ID INT AUTO_INCREMENT، نام VARCHAR(100)، بنیادی کلید (id)؛ اب ایک تیسرا ٹیبل بناتے ہیں جس میں ہمارے مصنف اور کتاب کے ٹیبل سے دو غیر ملکی کیز ہوں گی اور یہ لنک منفرد ہوگا۔ یعنی، ایک ہی کلید کے ساتھ دو بار ریکارڈ شامل کرنا ممکن نہیں ہو گا: TABLE مصنفین_x_books بنائیں ( book_id INT NOT NULL، author_id INT NOT NULL، FOREIGN KEY (book_id) حوالہ جات کتاب (id)، فارن کلید (author_id) REFERENCES (id ) , UNIQUE (book_id، author_id) )؛ یہاں ہم نے کئی نئی خصوصیات استعمال کی ہیں جن پر الگ سے تبصرہ کرنے کی ضرورت ہے:

• NOT NULL کا مطلب ہے کہ فیلڈ کو ہمیشہ بھرنا چاہیے، اور اگر ہم ایسا نہیں کرتے ہیں تو ایس کیو ایل ہمیں بتائے گا؛
• UNIQUE کا کہنا ہے کہ ٹیبل میں فیلڈ یا فیلڈز کا ایک گروپ منفرد ہونا چاہیے۔ ایسا اکثر ہوتا ہے کہ منفرد شناخت کنندہ کے علاوہ، ایک اور فیلڈ ہر ریکارڈ کے لیے منفرد ہونا چاہیے۔ اور UNIQUE بالکل اس معاملے کے لیے ذمہ دار ہے۔

میری پریکٹس سے: پرانے سسٹم سے نئے سسٹم میں منتقل ہونے پر، ہمیں، بطور ڈیولپر، پرانے سسٹم کے آئی ڈیز کو اس کے ساتھ کام کرنے اور خود بنانے کے لیے اسٹور کرنا چاہیے۔ کیوں آپ خود بنائیں اور پرانے استعمال نہ کریں؟ ہو سکتا ہے وہ کافی منفرد نہ ہوں، یا IDs بنانے کا یہ طریقہ اب متعلقہ اور محدود نہیں رہ سکتا ہے۔ اس مقصد کے لیے ہم نے جدول میں پرانے شناختی نام کو بھی منفرد بنایا ہے۔ اسے چیک کرنے کے لیے، آپ کو ڈیٹا شامل کرنے کی ضرورت ہے۔ ایک کتاب اور مصنف شامل کریں: NSERT INTO book (name) VALUES ("book1")؛ مصنف (نام) VALUES ("author1") میں داخل کریں؛ ہم پچھلے مضامین سے پہلے ہی جان چکے ہیں کہ ان کے پاس IDs 1 اور 1 ہوں گے۔ لہذا، ہم فوری طور پر تیسرے ٹیبل میں ایک ریکارڈ شامل کر سکتے ہیں: INSERT INTO authors_x_books VALUES (1,1); اور سب کچھ اس وقت تک ٹھیک رہے گا جب تک کہ ہم آخری کمانڈ کو دوبارہ دہرانا نہیں چاہتے ہیں: یعنی وہی آئی ڈی دوبارہ لکھیں: نتیجہ قدرتی ہوگا - ایک غلطی۔ ایک ڈپلیکیٹ ہوگا۔ اندراج ریکارڈ نہیں کیا جائے گا۔ اس طرح کئی سے کئی کنکشن بنیں گے... یہ سب بہت اچھا اور دلچسپ ہے، لیکن ایک منطقی سوال پیدا ہوتا ہے: یہ معلومات کیسے حاصل کی جائیں؟ مختلف جدولوں کے ڈیٹا کو ایک ساتھ کیسے ملایا جائے اور ایک جواب حاصل کیا جائے؟ یہ وہی ہے جس کے بارے میں ہم اگلے حصے میں بات کریں گے))

کنکشنز (جوائنز)

پچھلے حصے میں، میں نے آپ کو فوری طور پر یہ سمجھنے کے لیے تیار کیا تھا کہ جوائن کیا ہے اور انہیں کہاں استعمال کرنا ہے۔ کیونکہ مجھے گہرا یقین ہے کہ جیسے ہی سمجھ آجائے گی، سب کچھ فوری طور پر بہت آسان ہو جائے گا، اور جوائن کے بارے میں تمام مضامین بچے کی آنکھوں کی طرح واضح ہو جائیں گے :D موٹے طور پر اور عمومی طور پر، جوائنز کا نتیجہ کئی ٹیبلز سے حاصل ہو رہا ہے۔ جوائن کا (انگریزی جوائن سے شامل ہونا)۔ اور بس...) اور شامل ہونے کے لیے، آپ کو اس فیلڈ کی وضاحت کرنی ہوگی جس کے ذریعے ٹیبلز کو جوائن کیا جائے گا۔ شیطان اتنا خوفناک نہیں ہے جتنا اسے پینٹ کیا گیا ہے، ٹھیک ہے؟) اگلا، ہم صرف اس بات کے بارے میں بات کریں گے کہ وہاں کس قسم کے جوڑ ہیں اور انہیں کیسے استعمال کیا جائے۔ جوائن کی بہت سی قسمیں ہیں، اور ہم ان سب پر غور نہیں کریں گے۔ صرف وہی جن کی ہمیں واقعی ضرورت ہے۔ اسی لیے ہمیں کراس اور نیچرل جیسے غیر ملکی جوڑ میں دلچسپی نہیں ہے۔ میں مکمل طور پر بھول گیا، ہمیں ایک اور نزاکت یاد رکھنے کی ضرورت ہے: ٹیبلز اور فیلڈز کے عرفی نام ہو سکتے ہیں۔ وہ آسانی سے شمولیت کے لیے استعمال ہوتے ہیں۔ مثال کے طور پر، آپ یہ کر سکتے ہیں: SELECT * FROM table1؛ اگر استفسار اکثر table1 کا استعمال کرے گا، تو آپ اسے ایک عرف دے سکتے ہیں: t1 کے طور پر table1 سے SELECT*؛ یا اس سے بھی آسان لکھنا: SELECT * FROM table1 t1; اور پھر بعد میں استفسار میں t1 کو اس ٹیبل کے عرف کے طور پر استعمال کرنا ممکن ہوگا۔

اندرونی شرکت

سب سے عام اور سادہ شمولیت۔ یہ کہتا ہے کہ جب ہمارے پاس دو میزیں اور ایک فیلڈ ہے جس کے ذریعے اسے جوڑا جا سکتا ہے، تو وہ تمام ریکارڈز منتخب کیے جائیں گے جن کے تعلقات دونوں جدولوں میں موجود ہیں۔ کسی طرح کہنا مشکل تھا۔ آئیے ایک مثال دیکھیں: آئیے اپنے شہروں کے ڈیٹا بیس میں ایک ریکارڈ شامل کریں۔ ایک اندراج شہروں کے لیے اور ایک ممالک کے لیے: $ INSERT INTO country VALUES(5, "Uzbekistan", 34036800); اور $ INSERT INTO city (نام، آبادی) VALUES("Tbilisi", 1171100); ہم نے ایک ایسا ملک شامل کیا جس کا ہمارے ٹیبل میں کوئی شہر نہیں ہے، اور ایک ایسا شہر جو ہمارے ٹیبل میں کسی ملک سے وابستہ نہیں ہے۔ لہذا، INNER JOIN ان کنکشنز کے تمام ریکارڈ جاری کرنے میں مصروف ہے جو دو میزوں میں ہیں۔ جب ہم دو ٹیبلز table1 اور table2 کو جوائن کرنا چاہتے ہیں تو عمومی نحو کی طرح دکھائی دیتی ہے: t1.id = t2.t1_id پر ٹیبل 1 ٹی1 کے اندرونی جوائن ٹیبل2 کو منتخب کریں؛ اور پھر وہ تمام ریکارڈز واپس کر دیے جائیں گے جن کا دونوں ٹیبلز میں رشتہ ہے۔ ہمارے معاملے میں، جب ہم شہروں کے ساتھ ساتھ ممالک کے لیے معلومات حاصل کرنا چاہتے ہیں، تو یہ اس طرح نکلے گا: $ SELECT * FROM city ci INNER JOIN country co ON ci.country_id = co.id؛ یہاں، اگرچہ نام ایک جیسے ہیں، آپ واضح طور پر دیکھ سکتے ہیں کہ شہروں کے میدان پہلے آتے ہیں، پھر ممالک کے میدان۔ لیکن ہم نے اوپر جو دو اندراجات شامل کیے ہیں وہ وہاں نہیں ہیں۔ کیونکہ INNER JOIN بالکل اسی طرح کام کرتا ہے۔

بائیں شمولیت

ایسے معاملات ہوتے ہیں، اور اکثر، جب ہم مرکزی میز کے کھیتوں کے کھو جانے سے مطمئن نہیں ہوتے ہیں اس حقیقت کی وجہ سے کہ ملحقہ ٹیبل میں اس کا کوئی ریکارڈ نہیں ہے۔ لیفٹ جوائن اسی کے لیے ہے۔ اگر ہماری پچھلی درخواست میں ہم INNER کے بجائے بائیں طرف بتاتے ہیں، تو ہم جواب میں ایک اور شہر شامل کریں گے - تبلیسی: $ SELECT * FROM city ci LEFT JOIN country co ON ci.country_id = co.id؛ تبلیسی کے بارے میں ایک نیا اندراج ہے اور ملک سے متعلق ہر چیز کالعدم ہے ۔ یہ اکثر اس طرح استعمال ہوتا ہے۔

رائٹ جوائن

یہاں لیفٹ جوائن سے فرق یہ ہوگا کہ کنکشن میں تمام فیلڈز بائیں جانب نہیں بلکہ دائیں جانب منتخب ہوں گی۔ یعنی شہر نہیں بلکہ تمام ممالک لیے جائیں گے: $SELECT * FROM city ci RIGHT JOIN country co ON ci.country_id = co.id; اب یہ واضح ہے کہ اس معاملے میں تبلیسی نہیں ہوگا، لیکن ہمارے پاس ازبکستان ہوگا۔ کچھ ایسا ہی…))

محفوظ جوائنز

اب میں آپ کو ایک عام تصویر دکھانا چاہتا ہوں جسے انٹرویو سے پہلے جونیئرز اس بات پر راضی کرتے ہیں کہ وہ جوائن کے جوہر کو سمجھتے ہیں: یہاں سب کچھ سیٹ کی شکل میں دکھایا گیا ہے، ہر دائرہ ایک میز ہے۔ اور وہ جگہیں جہاں اس پر پینٹ کیا گیا ہے وہ حصے ہیں جو SELECT میں دکھائے جائیں گے۔ آئیں دیکھیں:

• INNER JOIN صرف سیٹوں کا چوراہا ہے، یعنی وہ ریکارڈ جو دو میزوں سے جڑے ہوئے ہیں - A اور B؛
• لیفٹ جوائن ٹیبل A کے تمام ریکارڈز ہیں، بشمول ٹیبل B کے وہ تمام ریکارڈ جن کا A کے ساتھ انٹرسیکشن (کنکشن) ہے۔
• رائٹ جوائن بائیں شمولیت کے بالکل برعکس ہے - ٹیبل B میں تمام ریکارڈز اور A کے ریکارڈز جن کا تعلق ہے۔

اس سب کے بعد، یہ تصویر واضح ہونا چاہئے))

گھر کا کام

اس بار کام بہت دلچسپ ہوں گے اور وہ تمام لوگ جو انہیں کامیابی کے ساتھ حل کرتے ہیں وہ یقین دہانی کر سکتے ہیں کہ وہ SQL سائیڈ پر کام شروع کرنے کے لیے تیار ہیں! کاموں کو چبایا نہیں گیا ہے اور یہ مڈل طلباء کے لیے لکھے گئے ہیں، اس لیے یہ آپ کے لیے آسان اور بورنگ نہیں ہوگا :) میں آپ کو ایک ہفتہ کا وقت دوں گا تاکہ وہ کام خود کریں، اور پھر میں تفصیلی تجزیہ کے ساتھ ایک الگ مضمون شائع کروں گا۔ ان کاموں کا حل جو میں نے آپ کو دیا تھا۔

اصل کام:

1. درج ذیل فیلڈز کے ساتھ 'سٹوڈنٹ' ٹیبل بنانے کے لیے ایس کیو ایل اسکرپٹ لکھیں: آئی ڈی (بنیادی کلید)، نام، آخری نام، ای میل (منفرد)۔
2. درج ذیل فیلڈز کے ساتھ 'کتاب' ٹیبل بنانے کے لیے ایک SQL اسکرپٹ لکھیں: id، عنوان (id + title = بنیادی کلید)۔ 'طالب علم' اور 'کتاب' کو 'طالب علم' ایک سے کئی 'کتاب' کے تعلق سے جوڑیں۔
3. درج ذیل فیلڈز کے ساتھ 'ٹیچر' ٹیبل بنانے کے لیے ایس کیو ایل اسکرپٹ لکھیں: آئی ڈی (بنیادی کلید)، نام، آخری نام، ای میل (منفرد)، موضوع۔
4. 'طالب علم' اور 'استاد' کو 'طالب علم' کے کئی سے کئی اساتذہ کے رشتے سے جوڑیں۔
5. 'طالب علم' کو منتخب کریں جن کے آخری نام میں 'oro' ہے، مثال کے طور پر 'Sid oro v'، 'V oro novsky'۔
6. 'طالب علم' ٹیبل سے تمام آخری نام ('آخری_نام') اور ان کی تکرار کی تعداد منتخب کریں۔ اس بات پر غور کریں کہ ڈیٹا بیس میں نام موجود ہیں۔ نزولی ترتیب میں مقدار کے لحاظ سے ترتیب دیں۔ یہ اس طرح نظر آنا چاہئے:

   آخری_نام	مقدار
   پیٹروف	15
   ایوانوف	12
   سیدوروف	3

7. 'طالب علم' سے سب سے اوپر 3 سب سے زیادہ دہرائے جانے والے ناموں کو منتخب کریں۔ نزولی ترتیب میں مقدار کے لحاظ سے ترتیب دیں۔ یہ اس طرح نظر آنا چاہئے:

   نام	مقدار
   سکندر	27
   سرجی	10
   پیٹر	7

8. 'طلباء' کو منتخب کریں جن کے پاس 'کتاب' اور منسلک 'استاد' کی سب سے زیادہ تعداد ہے۔ نزولی ترتیب میں مقدار کے لحاظ سے ترتیب دیں۔ یہ اس طرح نظر آنا چاہئے:

   استاد کا آخری_نام	طالب علم کا آخری_نام	کتاب کی مقدار
   پیٹروف	سیدوروف	7
   ایوانوف	سمتھ	5
   پیٹروف	کانکاوا ۔	2>

9. اپنے تمام 'طالب علم' میں سے 'استاد' کو منتخب کریں جس کے پاس 'کتاب' کی سب سے زیادہ تعداد ہو۔ نزولی ترتیب میں مقدار کے لحاظ سے ترتیب دیں۔ یہ اس طرح نظر آنا چاہئے:

   استاد کا آخری_نام	کتاب کی مقدار
   پیٹروف	9
   ایوانوف	5

10. 'استاد' کو منتخب کریں جس کے تمام 'طالب علم' کے لیے 'کتاب' کی تعداد 7 اور 11 کے درمیان ہو۔ نزولی ترتیب میں مقدار کے لحاظ سے ترتیب دیں۔ یہ اس طرح نظر آنا چاہئے:

    استاد کا آخری_نام	کتاب کی مقدار
    پیٹروف	گیارہ
    سیدوروف	9
    ایوانوف	7

11. تمام 'استاد' اور 'طالب علم' کے تمام 'آخری_نام' اور 'نام' کو فیلڈ 'ٹائپ' (طالب علم یا استاد) کے ساتھ پرنٹ کریں۔ حروف تہجی کے لحاظ سے 'last_name' سے ترتیب دیں۔ یہ اس طرح نظر آنا چاہئے:

    آخری_نام	قسم
    ایوانوف	طالب علم
    کانکاوا ۔	استاد
    سمتھ	طالب علم
    سیدوروف	استاد
    پیٹروف	استاد

12. موجودہ 'سٹوڈنٹ' ٹیبل میں ایک 'ریٹ' کالم شامل کریں، جو اس کورس کو محفوظ کرے گا جس میں طالب علم فی الحال ہے (1 سے 6 تک عددی قدر)۔
13. اس آئٹم کی ضرورت نہیں ہے، لیکن یہ ایک پلس ہوگا۔ ایک فنکشن لکھیں جو تمام 'کتابوں' سے گزرے گا اور تمام 'ٹائٹلز' کو کوما سے الگ کر کے آؤٹ پٹ کرے گا۔

نتیجہ

ڈیٹا بیس کے بارے میں سیریز کو تھوڑا سا گھسیٹ لیا گیا ہے۔ متفق۔ تاہم، ہم نے ایک طویل راستہ طے کیا ہے اور اس کے نتیجے میں ہم اس معاملے کے علم کے ساتھ ابھرتے ہیں! پڑھنے کے لیے آپ سب کا شکریہ، میں آپ کو یاد دلاتا ہوں کہ ہر وہ شخص جو آگے بڑھنا اور اس پراجیکٹ کی پیروی کرنا چاہتا ہے اسے GitHub پر ایک اکاؤنٹ بنانا ہوگا اور میرے اکاؤنٹ کو سبسکرائب کرنا ہوگا :) مزید آنے والے ہیں - آئیے Maven اور Docker کے بارے میں بات کرتے ہیں۔ پڑھنے کے لیے سب کا شکریہ۔ میں ایک بار پھر دہراتا ہوں: جو چلتا ہے وہ سڑک پر عبور حاصل کرے گا؛)

سیریز کے تمام مواد کی فہرست اس مضمون کے شروع میں ہے۔