اسان ڊيٽابيس ۽ SQL ٻولي جو تجزيو ڪريون ٿا. (حصو 5 - ڪنيڪشن ۽ شامل ٿيڻ) - "جاوا پروجيڪٽ A کان Z تائين"

جاوا پروجيڪٽ ٺاهڻ بابت هڪ سيريز مان هڪ مضمون (ٻين مواد جي لنڪ آخر ۾ آهن). ان جو مقصد اهم ٽيڪنالاجي جو تجزيو ڪرڻ آهي، نتيجو هڪ ٽيليگرام بوٽ لکڻ آهي.

• ڊيٽابيس ۾ رشتن جا قسم
  • هڪ کان گهڻا
  • هڪ کان هڪ (هڪ کان هڪ)
  • گهڻن کان گهڻا
• رابطا (شامل)
  • اندروني شموليت
  • کاٻي ۾ شامل ٿيو
  • حق ۾ شامل ٿيو
  • محفوظ شامل ٿيڻ
• گهر جو ڪم

هيلو هرڪو، مستقبل جي سينيئر ۽ سافٽ ويئر جي سينيئرٽس. جيئن مون پوئين حصي ۾ چيو هو ( هوم ورڪ چيڪ ڪرڻ )، اڄ اتي نئون مواد هوندو. انهن لاءِ جيڪي خاص طور تي شوقين آهن، مون هڪ دلچسپ هوم ورڪ اسائنمينٽ تيار ڪئي آهي ته جيئن اهي جيڪي اڳ ۾ ئي سڀ ڪجهه ڄاڻن ٿا ۽ جيڪي نه ٿا ڄاڻن پر گوگل ڪرڻ چاهين ٿا، اهي مشق ڪري سگهن ۽ انهن جي صلاحيتن کي جانچي سگهن. اڄ اسان ڪنيڪشن ۽ جوائن جي قسمن بابت ڳالهائينداسين.

ڊيٽابيس ۾ رشتن جا قسم

سمجھڻ لاءِ ڪھڙا رشتا آھن، توھان کي ياد رکڻ گھرجي ته ھڪ غير ملڪي چاٻي ڇا آھي. انهن لاءِ جيڪي وسري ويا، سيريز جي شروعات ۾ ڀليڪار .

هڪ کان گهڻا

اچو ته اسان جي مثال کي ملڪن ۽ شهرن سان ياد رکون. اهو واضح آهي ته هڪ شهر جو هڪ ملڪ هجڻ گهرجي. هڪ ملڪ کي شهر سان ڪيئن ڳنڍجي؟ اهو ضروري آهي ته هر شهر سان ڳنڍڻ لاء هڪ منفرد سڃاڻپ ڪندڙ (ID) ملڪ جو تعلق آهي: اسان اڳ ۾ ئي ڪيو آهي. هن کي ڪنيڪشن جي قسمن مان هڪ سڏيو ويندو آهي - هڪ کان گهڻن (اهو پڻ سٺو ٿيندو ته انگريزي ورزن کي ڄاڻڻ لاء - هڪ کان گهڻن). بيان ڪرڻ لاء، اسان اهو چئي سگهون ٿا: ڪيترن ئي شهرن جو تعلق هڪ ملڪ سان ٿي سگهي ٿو. اهو ڪيئن توهان کي ياد رکڻ گهرجي: هڪ هڪ کان گهڻا تعلق. ايترو پري اهو واضح آهي، صحيح؟ جيڪڏهن نه، پوء هتي انٽرنيٽ کان پهرين تصوير آهي: اهو ڏيکاري ٿو ته اتي گراهڪ ۽ انهن جا حڪم آهن. اهو احساس ڪري ٿو ته هڪ گراهڪ هڪ کان وڌيڪ آرڊر ڪري سگهي ٿو. هتي هڪ کان گھڻا آهن :) يا ٻيو مثال: ٽي جدول آهن: پبلشر، ليکڪ ۽ ڪتاب. هر پبلشر جيڪو نه ٿو چاهي ته ديوار ٿي وڃي ۽ ڪامياب ٿيڻ چاهي ٿو هڪ کان وڌيڪ ليکڪ آهن، ڇا توهان متفق نه آهيو؟ موڙ ۾، هر ليکڪ هڪ کان وڌيڪ ڪتاب ٿي سگهي ٿو - ان ۾ ڪو به شڪ نه ٿي سگهي ٿو. ۽ ان جو مطلب، ٻيهر، هڪ ليکڪ جو ڪيترن ئي ڪتابن سان، هڪ پبلشر جو ڪيترن ئي ليکڪن سان تعلق . ان کانسواءِ ٻيا به ڪيترائي مثال ڏئي سگهجن ٿا. تصور ۾ مشڪل پهرين ۾ صرف تجريدي طور تي سوچڻ سکڻ ۾ ڪوڙ ٿي سگهي ٿي: ٽيبل تي ٻاهران ڏسڻ ۽ انهن جي رابطي ۾.

هڪ کان هڪ (هڪ کان هڪ)

اهو چئي سگهجي ٿو ته هڪ کان گهڻن رابطي جي هڪ خاص صورت آهي. اهڙي صورتحال جنهن ۾ هڪ ٽيبل ۾ هڪ رڪارڊ ٻئي ٽيبل ۾ صرف هڪ رڪارڊ سان لاڳاپيل آهي. زندگيءَ مان ڪهڙا مثال ٿي سگهن ٿا؟ جيڪڏهن اسان ڪثرت ازدواج کي خارج ڪريون ته پوءِ چئي سگهون ٿا ته مڙس ۽ زال جي وچ ۾ هڪ ٻئي سان تعلق آهي. جيتوڻيڪ جيڪڏهن اسان چئون ٿا ته تعدد ازدواج جي اجازت آهي، تڏهن به هر زال کي فقط هڪ مڙس ٿي سگهي ٿو. ساڳيو ئي ماء پيء جي باري ۾ چئي سگهجي ٿو. هر ماڻهوءَ جو فقط هڪ حياتياتي پيءُ ۽ فقط هڪ حياتياتي ماءُ ٿي سگهي ٿي. واضح هڪ کان هڪ تعلق. جڏهن مان هي لکي رهيو هئس، تڏهن مون کي هڪ خيال آيو ته: پوءِ ڇو ون ٽو ون رشتي کي ٻن رڪارڊن ۾ جدا جدا جدولن ۾ ورهايو وڃي، جيڪڏهن انهن ۾ اڳ ۾ ئي هڪ ٻئي سان تعلق آهي؟ مان پاڻ جواب وٺي آيو آهيان. اهي رڪارڊ شايد ٻين طريقن سان ٻين رڪارڊ سان ڳنڍيل هوندا. مان ڪهڙي ڳالهه ڪري رهيو آهيان؟ ملڪ ۽ صدر جي وچ ۾ ون ٽو ون رابطن جو ٻيو مثال آهي. ڇا اهو ممڪن آهي ته "ملڪ" جي ٽيبل ۾ صدر جي باري ۾ سڀ ڊيٽا لکندا؟ ها، توهان ڪري سگهو ٿا، SQL هڪ لفظ نه چوندا. پر جيڪڏهن توهان سوچيو ته صدر پڻ هڪ شخص آهي ... ۽ هن کي به زال هجي (ٻيو هڪ سان تعلق) ۽ ٻار (ٻيو هڪ کان گهڻا تعلق) ۽ پوء اهو ظاهر ٿئي ٿو ته اهو ٿيندو. ملڪ کي صدر جي زال ۽ ٻارن سان ڳنڍڻ ضروري آهي. چريو لڳي ٿو، صحيح؟ :D ان سلسلي جا ٻيا به ڪيترائي مثال ٿي سگھن ٿا. ان کان علاوه، اهڙي صورتحال ۾، توهان ٻنهي جدولن ۾ هڪ غير ملڪي ڪيئي شامل ڪري سگهو ٿا، هڪ کان گهڻن رشتي جي برعڪس.

گهڻن کان گهڻا

اڳ ۾ ئي نالي جي بنياد تي، توهان اندازو لڳائي سگهو ٿا ته اسان ڇا ڳالهائينداسين. اڪثر زندگي ۾، ۽ اسان اسان جي زندگين کي پروگرام ڪندا آهيون، اهي حالتون آهن جڏهن مٿين قسم جا ڪنيڪشن ڪافي نه آهن انهن شين کي بيان ڪرڻ لاء جيڪي اسان کي گهربل آهن. اسان اڳ ۾ ئي پبلشرن، ڪتابن ۽ ليکڪن بابت ڳالهايو آهي. هتي تمام گهڻا ڪنيڪشن آهن... هر پبليڪيشن جا ڪيترائي ليکڪ ٿي سگهن ٿا - هڪ کان گهڻن ڪنيڪشن. ساڳئي وقت، هر ليکڪ جا ڪيترائي پبلشر ٿي سگهن ٿا (ڇو نه، ليکڪ هڪ جاء تي شايع ڪيو ويو، پئسن تي وڙهندي هئي، ڪنهن ٻئي پبلشنگ هائوس ڏانهن ويو، مثال طور). ۽ هي وري هڪ کان گھڻا تعلق آهي. يا هي: هر ليکڪ جا ڪيترائي ڪتاب ٿي سگهن ٿا، پر هر ڪتاب ۾ ڪيترائي ليکڪ به ٿي سگهن ٿا. وري، ليکڪ ۽ ڪتاب، ڪتاب ۽ ليکڪ جي وچ ۾ هڪ کان گهڻا تعلق. هن مثال مان اسان هڪ وڌيڪ رسمي نتيجو ڪڍي سگهون ٿا: اهو واضح هو ته SQL ۾ اڳئين ڪنيڪشن جي قسمن کي ڪيئن سيٽ ڪيو وڃي: اسان صرف ان جي سڃاڻپ کي انهن رڪارڊن ڏانهن منتقل ڪريون ٿا، جن مان ڪيترائي آهن، صحيح؟ هڪ ملڪ ڪيترن ئي شهرن کي پنهنجي سڃاڻپ هڪ پرڏيهي ڪنجي طور ڏئي ٿو. گھڻن کان گھڻن رشتن سان ڇا ڪجي ؟ اهو طريقو مناسب ناهي. اسان کي هڪ ٻيو ٽيبل شامل ڪرڻو پوندو جيڪو ٻن ٽيبلن کي ڳنڍيندو. مثال طور، اچو ته MySQL ڏانھن وڃو، ھڪڙو نئون ڊيٽابيس manytomany ٺاھيو، ٻه جدول ٺاھيو، ليکڪ ۽ ڪتاب، جنھن ۾ صرف نالا ۽ انھن جي سڃاڻپ ھوندي: CREATE DATABASE manytomany؛ ڪيترن ئي استعمال ڪريو؛ ٺاھيو ٽيبل ليکڪ (ID INT AUTO_INCREMENT، نالو VARCHAR(100)، پرائمري ڪي (id) )؛ ٽيبل ڪتاب ٺاھيو (ID INT AUTO_INCREMENT، نالو VARCHAR (100)، پرائمري ڪي (id) )؛ هاڻي اچو ته هڪ ٽيون ٽيبل ٺاهيون جنهن ۾ اسان جي ليکڪ ۽ ڪتاب جي ٽيبل مان ٻه پرڏيهي ڪنجيون هونديون ۽ اها لنڪ منفرد هوندي. اهو آهي، اهو ممڪن نه هوندو ته هڪ رڪارڊ کي ٻه ڀيرا ساڳيون چابيون سان شامل ڪيو وڃي: CREATE TABLE authors_x_books (book_id INT NOT NULL، author_id INT NOT NULL، FOREIGN KEY (book_id) حوالو ڪتاب(id)، FOREIGN KEY (author_id) REFERENCES. (id)، UNIQUE (book_id، author_id) )؛ هتي اسان ڪيترائي نوان خاصيتون استعمال ڪيا آهن جن تي الڳ الڳ تبصرو ڪرڻ جي ضرورت آهي:

• NOT NULL جو مطلب آهي ته فيلڊ هميشه ڀريو وڃي، ۽ جيڪڏهن اسان نه ڪيو، SQL اسان کي ٻڌائيندو؛
• UNIQUE چوي ٿو ته هڪ فيلڊ يا فيلڊ جو هڪ گروپ ٽيبل ۾ منفرد هجڻ گهرجي. اهو اڪثر ٿئي ٿو ته منفرد سڃاڻپ ڪندڙ کان علاوه، هڪ وڌيڪ فيلڊ هر رڪارڊ لاء منفرد هجڻ گهرجي. ۽ UNIQUE هن معاملي لاء ذميوار آهي.

منهنجي عمل مان: جڏهن هڪ پراڻي سسٽم مان هڪ نئين ڏانهن منتقل ڪيو وڃي، اسان کي، ڊولپرز جي طور تي، ان سان گڏ ڪم ڪرڻ لاء پراڻي سسٽم جي ID کي ذخيرو ڪرڻ گهرجي ۽ پنهنجو پاڻ ٺاهيو. ڇو پنهنجو پاڻ ٺاهيو ۽ پراڻن کي استعمال نه ڪيو؟ اهي شايد ڪافي منفرد نه هجن، يا IDs ٺاهڻ جو اهو طريقو هاڻي لاڳاپيل ۽ محدود نه هجي. ان مقصد لاءِ، اسان ٽيبل ۾ پراڻي سڃاڻپ جو نالو پڻ منفرد ڪيو. ھن کي چيڪ ڪرڻ لاء، توھان کي ڊيٽا شامل ڪرڻ جي ضرورت آھي. ڪتاب ۽ ليکڪ شامل ڪريو: NSERT INTO book (name) VALUES ("book1"); INSERT INTO ليکڪ (نالو) VALUES ("author1")؛ اسان اڳئين مضمونن مان ڄاڻون ٿا ته انھن وٽ IDs 1 ۽ 1 ھوندا. ان ڪري، اسين فوري طور تي ٽئين جدول ۾ رڪارڊ شامل ڪري سگھون ٿا: INSERT INTO authors_x_books VALUES (1,1); ۽ سڀ ڪجھ ٺيڪ ٿي ويندو جيستائين اسان آخري حڪم کي ٻيهر ورجائڻ چاهيون ٿا: اهو آهي، ساڳيا ID ٻيهر لکو: نتيجو قدرتي ٿيندو - هڪ غلطي. اتي هڪ نقل ٿيندو. داخلا رڪارڊ نه ڪئي ويندي. اهڙيءَ طرح هڪ کان گھڻا لاڳاپا پيدا ٿيندا... هي سڀ ڪجهه تمام ٿڌو ۽ دلچسپ آهي، پر هڪ منطقي سوال پيدا ٿئي ٿو ته: اها معلومات ڪيئن حاصل ڪجي؟ ڪيئن مختلف جدولن مان ڊيٽا گڏ ڪرڻ ۽ هڪ جواب حاصل ڪرڻ لاء؟ اھو اھو آھي جيڪو اسان ايندڙ حصي ۾ ڳالهائينداسين))

رابطا (شامل)

پوئين حصي ۾، مون توهان کي فوري طور تي سمجھڻ لاء تيار ڪيو ته ڇا شامل آهن ۽ انهن کي ڪٿي استعمال ڪجي. ڇاڪاڻ ته مون کي يقين آهي ته جيئن ئي سمجهه ايندي، سڀ ڪجهه فوري طور تي بلڪل سادو ٿي ويندو، ۽ شامل ٿيڻ بابت سڀئي مضمون هڪ ٻار جي اکين وانگر واضح ٿي ويندا:D تقريبن ۽ عام طور تي، شامل ٿيڻ جي ذريعي ڪيترن ئي جدولن مان نتيجو حاصل ڪري رهيا آهن. جوائن جو (انگريزي جوائن مان شامل ٿيو). ۽ اهو سڀ ڪجهه آهي...) ۽ شامل ٿيڻ لاءِ، توهان کي فيلڊ جي وضاحت ڪرڻي پوندي جنهن سان ٽيبل شامل ڪيا ويندا. شيطان ايترو خوفناڪ نه آهي جيترو هن کي رنگايو ويو آهي، صحيح؟) اڳيون، اسان صرف ان بابت ڳالهائينداسين ته ڪهڙي قسم جا شامل آهن ۽ انهن کي ڪيئن استعمال ڪجي. اتي ڪيترائي قسم جا شامل آھن، ۽ اسان انھن سڀني تي غور نه ڪنداسين. صرف اهي جيڪي اسان کي واقعي جي ضرورت آهي. اهو ئي سبب آهي ته اسان کي اهڙي غير ملڪي جوائن ۾ دلچسپي نه آهي جيئن ڪراس ۽ قدرتي. مون کي مڪمل طور تي وساريو، اسان کي هڪ وڌيڪ nuance ياد ڪرڻ جي ضرورت آهي: جدولن ۽ شعبن aliases ٿي سگهي ٿو - تخلص. اهي آسانيء سان شامل ٿيڻ لاء استعمال ڪيا ويا آهن. مثال طور، توھان ھي ڪري سگھو ٿا: SELECT * FROM table1؛ جيڪڏهن سوال اڪثر ڪري table1 استعمال ڪندو، ته پوء توهان ان کي هڪ عرف ڏئي سگهو ٿا: SELECT* FROM table1 جيئن t1؛ يا لکڻ ۾ اڃا به آسان: SELECT * FROM table1 t1؛ ۽ پوءِ بعد ۾ سوال ۾ اهو ممڪن ٿيندو ته t1 کي هن ٽيبل لاءِ عرف طور استعمال ڪيو وڃي.

اندروني شموليت

سڀ کان وڌيڪ عام ۽ سادي شامل ٿيڻ. اهو چوي ٿو ته جڏهن اسان وٽ ٻه جدول آهن ۽ هڪ فيلڊ جنهن جي ذريعي ان کي شامل ڪري سگهجي ٿو، اهي سڀئي رڪارڊ جن جا لاڳاپا ٻن جدولن ۾ موجود آهن چونڊيا ويندا. اهو ڪجهه چوڻ ڏکيو هو. اچو ته هڪ مثال ڏسو: اچو ته هڪ رڪارڊ شامل ڪريون اسان جي شهرن جي ڊيٽابيس ۾. هڪ داخلا شهرن لاءِ ۽ هڪ ملڪن لاءِ: $ INSERT INTO country VALUES(5, "Uzbekistan", 34036800); ۽ $ INSERT INTO شهر (نالو، آبادي) VALUES("Tbilisi"، 1171100)؛ اسان ھڪڙو ملڪ شامل ڪيو آھي جنھن جو اسان جي ٽيبل ۾ ھڪڙو شھر نه آھي، ۽ ھڪڙو شھر جيڪو اسان جي جدول ۾ ھڪڙي ملڪ سان لاڳاپيل نه آھي. تنهن ڪري، INNER JOIN انهن ڪنيڪشن جا سمورا رڪارڊ جاري ڪرڻ ۾ مصروف آهي جيڪي ٻن ٽيبلن ۾ آهن. ھي اھو آھي جيڪو عام نحو ڏسڻ ۾ اچي ٿو جڏھن اسان ٻن جدولن ۾ شامل ٿيڻ چاھيون ٿا ٽيبل 1 ۽ ٽيبل 2: SELECT * FROM table1 t1 INNER JOIN table2 ON t1.id = t2.t1_id؛ ۽ پوءِ سڀئي رڪارڊ جيڪي ٻن جدولن ۾ تعلق رکن ٿا واپس ڪيا ويندا. اسان جي ڪيس لاءِ، جڏھن اسين شھرن سان گڏ ملڪن جي معلومات حاصل ڪرڻ چاھيون ٿا، ته اھو ھن طرح ٿيندو: $ SELECT * FROM city ci INNER JOIN country co ON ci.country_id = co.id؛ هتي، جيتوڻيڪ نالا ساڳيا آهن، توهان صاف طور تي ڏسي سگهو ٿا ته پهرين شهرن جا شعبا اچن ٿا، پوء ملڪن جا شعبا. پر اهي ٻه داخلائون جيڪي اسان مٿي شامل ڪيون آهن اهي نه آهن. ڇاڪاڻ ته اهو ئي آهي ڪيئن اندروني شموليت ڪم ڪري ٿو.

کاٻي ۾ شامل ٿيو

اهڙا ڪيس آهن، ۽ اڪثر ڪري، جڏهن اسان بنيادي جدول جي فيلڊ جي نقصان کان مطمئن نه آهيون ڇاڪاڻ ته حقيقت اها آهي ته ڀرسان ٽيبل ۾ ان لاء ڪو رڪارڊ ناهي. اهو ئي آهي جيڪو هڪ کاٻي سان شامل ٿيڻ لاء آهي. جيڪڏهن اسان جي پوئين درخواست ۾ اسان INNER جي بدران LEFT بيان ڪريون ٿا، اسان جواب ۾ ٻيو شهر شامل ڪنداسين - Tbilisi: $ SELECT * FROM city ci LEFT JOIN country co ON ci.country_id = co.id; تبليسي جي باري ۾ هڪ نئون داخل ٿيو آهي ۽ هر شيء جيڪا ملڪ سان تعلق رکي ٿي ان کي رد ڪري ڇڏيو آهي . اهو اڪثر ڪري استعمال ڪيو ويندو آهي.

حق ۾ شامل ٿيو

هتي LEFT JOIN کان فرق هوندو ته سڀئي فيلڊس کاٻي پاسي نه پر ڪنيڪشن ۾ ساڄي پاسي چونڊيا ويندا. اهو آهي، شهر نه، پر سڀني ملڪن کي ورتو ويندو: $ SELECT * FROM city ci RIGHT JOIN country co ON ci.country_id = co.id; هاڻي اهو واضح آهي ته هن معاملي ۾ ڪو به تبليسي نه هوندو، پر اسان وٽ ازبڪستان هوندو. اهڙو ئي ڪجھہ…))

محفوظ شامل ٿيڻ

ھاڻي مان توھان کي ھڪ عام تصوير ڏيکارڻ چاھيان ٿو، جنھن ۾ جونيئر ھڪ انٽرويوءَ کان اڳ رڙ ڪري انھن کي قائل ڪن ٿا ته ھو جوائن جي جوڙ کي سمجھن ٿا: ھتي ھر شيءِ سيٽ جي صورت ۾ ڏيکاريل آھي، ھر دائرو ھڪ ٽيبل آھي. ۽ اھي جڳھون جتي اھو رنگ ڪيو ويو آھي اھي حصا آھن جيڪي SELECT ۾ ڏيکاريا ويندا. اچو ته ڏسون:

• INNER JOIN صرف سيٽن جو چونڪ آھي، اھو آھي، اھي رڪارڊ جيڪي ٻن جدولن سان ڪنيڪشن آھن - A ۽ B؛
• LEFT JOIN جدول A کان سڀ رڪارڊس آھن، بشمول ٽيبل B جا اھي سڀ رڪارڊ جن جو A سان ھڪ چوٽ (ڪنيڪشن) آھي؛
• ساڄي شموليت بلڪل کاٻي شموليت جي ابتڙ آهي - ٽيبل B ۾ سڀئي رڪارڊ ۽ A کان رڪارڊ جيڪي تعلق رکن ٿا.

ان کان پوء، هي تصوير صاف هجڻ گهرجي))

گهر جو ڪم

هن ڀيري ڪم ڏاڍا دلچسپ هوندا ۽ اهي سڀئي ماڻهو جيڪي انهن کي ڪاميابيءَ سان حل ڪن ٿا، يقين ڏياري سگهن ٿا ته اهي SQL پاسي تي ڪم شروع ڪرڻ لاءِ تيار آهن! اهي ڪم چٽا نه ڪيا ويا آهن ۽ مڊل شاگردن لاءِ لکيا ويا آهن، تنهنڪري اهو توهان لاءِ آسان ۽ بور ڪندڙ نه هوندو :) مان توهان کي ڪم پاڻ ڪرڻ لاءِ هڪ هفتو ڏيندس، ۽ پوءِ تفصيلي تجزيو سان هڪ الڳ مضمون شايع ڪندس. انهن ڪمن جو حل جيڪو مون توهان کي ڏنو آهي.

اصل ڪم:

1. هيٺ ڏنل شعبن سان 'شاگرد' جدول ٺاهڻ لاءِ SQL اسڪرپٽ لکو: id (پرائمري ڪيئي)، نالو، آخري_نام، اي ميل (منفرد).
2. هيٺ ڏنل شعبن سان 'ڪتاب' جدول ٺاهڻ لاءِ SQL اسڪرپٽ لکو: id، عنوان (id + title = پرائمري ڪي). ڳنڍيو ’شاگرد‘ ۽ ’ڪتاب‘ جو ’شاگرد‘ سان هڪ کان گهڻن ’ڪتاب‘ جو تعلق.
3. هيٺ ڏنل شعبن سان 'استاد' ٽيبل ٺاهڻ لاءِ SQL اسڪرپٽ لکو: id (پرائمري ڪيئي)، نالو، آخري_نالو، اي ميل (منفرد)، مضمون.
4. ڳنڍيو ’شاگرد‘ ۽ ’استاد‘ سان ’شاگرد‘ سان ڪيترن ئي استادن سان تعلق.
5. 'شاگرد' چونڊيو جن جي آخري نالي ۾ 'oro' آهي، مثال طور 'Sid oro v'، 'V oro novsky'.
6. 'شاگردن' جي ٽيبل مان چونڊيو سڀ آخري نالا ('last_name') ۽ انهن جي ورجائي جو تعداد. غور ڪريو ته ڊيٽابيس ۾ نالا آهن. مقدار جي لحاظ سان ترتيب ڏنل ترتيب ۾. اهو هن طرح ڏسڻ گهرجي:

   آخري نالو	مقدار
   پيٽروف	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 بابت ڳالهايون. پڙهڻ لاءِ سڀني جي مهرباني. مان هڪ ڀيرو ٻيهر ورجائي ٿو: جيڪو هلندو آهي اهو روڊ تي ماهر هوندو؛)

سيريز ۾ سڀني مواد جي هڪ فهرست هن مضمون جي شروعات ۾ آهي.