# ڈیٹا کے ساتھ کام کرنا: ریلیشنل ڈیٹابیسز | کی اسکیچ نوٹ ](../../sketchnotes/05-RelationalData.png)| |:---:| | ڈیٹا کے ساتھ کام کرنا: ریلیشنل ڈیٹابیسز - _[@nitya](https://twitter.com/nitya) کی اسکیچ نوٹ_ | امکان ہے کہ آپ نے ماضی میں معلومات ذخیرہ کرنے کے لیے اسپریڈشیٹ کا استعمال کیا ہو۔ آپ کے پاس قطاروں اور کالموں کا ایک سیٹ تھا، جہاں قطاروں میں معلومات (یا ڈیٹا) موجود تھیں، اور کالم معلومات کی وضاحت کرتے تھے (جسے کبھی کبھار میٹا ڈیٹا کہا جاتا ہے)۔ ریلیشنل ڈیٹابیس اسی بنیادی اصول پر مبنی ہے، جہاں ٹیبلز میں قطاریں اور کالم ہوتے ہیں، جو آپ کو معلومات کو متعدد ٹیبلز میں تقسیم کرنے کی اجازت دیتا ہے۔ یہ آپ کو پیچیدہ ڈیٹا کے ساتھ کام کرنے، نقل سے بچنے، اور ڈیٹا کو مختلف طریقوں سے دریافت کرنے میں لچک فراہم کرتا ہے۔ آئیے ریلیشنل ڈیٹابیس کے تصورات کو دریافت کرتے ہیں۔ ## [لیکچر سے پہلے کا کوئز](https://ff-quizzes.netlify.app/en/ds/quiz/8) ## سب کچھ ٹیبلز سے شروع ہوتا ہے ریلیشنل ڈیٹابیس کی بنیاد ٹیبلز پر ہوتی ہے۔ جیسے اسپریڈشیٹ میں، ایک ٹیبل کالموں اور قطاروں کا مجموعہ ہوتا ہے۔ قطار میں وہ ڈیٹا یا معلومات ہوتی ہیں جن کے ساتھ ہم کام کرنا چاہتے ہیں، جیسے کسی شہر کا نام یا بارش کی مقدار۔ کالم اس ڈیٹا کی وضاحت کرتے ہیں جو وہ ذخیرہ کرتے ہیں۔ آئیے اپنی دریافت کا آغاز ایک ٹیبل بنا کر کرتے ہیں جس میں شہروں کی معلومات ذخیرہ کی جائیں۔ ہم ان کے نام اور ملک سے شروع کر سکتے ہیں۔ آپ اسے درج ذیل ٹیبل میں ذخیرہ کر سکتے ہیں: | شہر | ملک | | -------- | ------------- | | ٹوکیو | جاپان | | اٹلانٹا | امریکہ | | آکلینڈ | نیوزی لینڈ | نوٹ کریں کہ **شہر**، **ملک** اور **آبادی** کے کالم نام اس ڈیٹا کی وضاحت کرتے ہیں جو ذخیرہ کیا جا رہا ہے، اور ہر قطار میں ایک شہر کی معلومات موجود ہیں۔ ## ایک ٹیبل کے طریقے کی خامیاں امکان ہے کہ اوپر دیا گیا ٹیبل آپ کو کافی مانوس لگ رہا ہو۔ آئیے اپنی بڑھتی ہوئی ڈیٹابیس میں کچھ اضافی ڈیٹا شامل کرتے ہیں - سالانہ بارش (ملی میٹر میں)۔ ہم 2018، 2019 اور 2020 کے سالوں پر توجہ مرکوز کریں گے۔ اگر ہم اسے ٹوکیو کے لیے شامل کریں، تو یہ کچھ اس طرح نظر آئے گا: | شہر | ملک | سال | مقدار | | ----- | ------- | ---- | ------ | | ٹوکیو | جاپان | 2020 | 1690 | | ٹوکیو | جاپان | 2019 | 1874 | | ٹوکیو | جاپان | 2018 | 1445 | آپ ہمارے ٹیبل میں کیا نوٹ کرتے ہیں؟ آپ دیکھ سکتے ہیں کہ ہم شہر اور ملک کا نام بار بار دہرا رہے ہیں۔ یہ کافی زیادہ اسٹوریج لے سکتا ہے، اور متعدد کاپیاں رکھنا غیر ضروری ہے۔ آخرکار، ٹوکیو کا صرف ایک ہی نام ہے جس میں ہم دلچسپی رکھتے ہیں۔ ٹھیک ہے، آئیے کچھ اور کوشش کرتے ہیں۔ ہر سال کے لیے نئے کالم شامل کرتے ہیں: | شہر | ملک | 2018 | 2019 | 2020 | | -------- | ------------- | ---- | ---- | ---- | | ٹوکیو | جاپان | 1445 | 1874 | 1690 | | اٹلانٹا | امریکہ | 1779 | 1111 | 1683 | | آکلینڈ | نیوزی لینڈ | 1386 | 942 | 1176 | اگرچہ یہ قطاروں کی نقل سے بچاتا ہے، لیکن یہ کچھ دیگر چیلنجز پیدا کرتا ہے۔ ہمیں ہر بار ایک نیا سال آنے پر اپنے ٹیبل کی ساخت میں ترمیم کرنی ہوگی۔ مزید یہ کہ، جیسے جیسے ہمارا ڈیٹا بڑھتا ہے، سالوں کو کالمز کے طور پر رکھنا ڈیٹا کو بازیافت کرنے اور اس پر حساب کتاب کرنے کو مزید مشکل بنا دے گا۔ اسی لیے ہمیں متعدد ٹیبلز اور تعلقات کی ضرورت ہوتی ہے۔ اپنے ڈیٹا کو تقسیم کرکے ہم نقل سے بچ سکتے ہیں اور اپنے ڈیٹا کے ساتھ کام کرنے میں زیادہ لچک حاصل کر سکتے ہیں۔ ## تعلقات کے تصورات آئیے اپنے ڈیٹا پر واپس آتے ہیں اور طے کرتے ہیں کہ ہم اسے کیسے تقسیم کرنا چاہتے ہیں۔ ہم جانتے ہیں کہ ہم اپنے شہروں کے لیے نام اور ملک کو ذخیرہ کرنا چاہتے ہیں، لہذا یہ شاید ایک ٹیبل میں بہترین کام کرے گا۔ | شہر | ملک | | -------- | ------------- | | ٹوکیو | جاپان | | اٹلانٹا | امریکہ | | آکلینڈ | نیوزی لینڈ | لیکن اگلا ٹیبل بنانے سے پہلے، ہمیں یہ معلوم کرنا ہوگا کہ ہر شہر کا حوالہ کیسے دیا جائے۔ ہمیں کسی قسم کے شناخت کنندہ، ID یا (تکنیکی ڈیٹابیس اصطلاح میں) پرائمری کی کی ضرورت ہے۔ پرائمری کی ایک ایسی ویلیو ہے جو ٹیبل میں ایک مخصوص قطار کی شناخت کے لیے استعمال ہوتی ہے۔ اگرچہ یہ خود ایک ویلیو پر مبنی ہو سکتی ہے (مثال کے طور پر ہم شہر کے نام کو استعمال کر سکتے ہیں)، لیکن یہ تقریباً ہمیشہ ایک نمبر یا دیگر شناخت کنندہ ہونا چاہیے۔ ہم نہیں چاہتے کہ ID کبھی تبدیل ہو، کیونکہ یہ تعلق کو توڑ دے گا۔ زیادہ تر معاملات میں آپ دیکھیں گے کہ پرائمری کی یا ID ایک خودکار طور پر تیار کردہ نمبر ہوگا۔ > ✅ پرائمری کی کو اکثر PK کے طور پر مختصر کیا جاتا ہے ### شہروں کا ٹیبل | city_id | شہر | ملک | | ------- | -------- | ------------- | | 1 | ٹوکیو | جاپان | | 2 | اٹلانٹا | امریکہ | | 3 | آکلینڈ | نیوزی لینڈ | > ✅ آپ نوٹ کریں گے کہ ہم اس سبق کے دوران "id" اور "پرائمری کی" کی اصطلاحات کو ایک دوسرے کے ساتھ استعمال کرتے ہیں۔ یہ تصورات ڈیٹا فریمز پر بھی لاگو ہوتے ہیں، جنہیں آپ بعد میں دریافت کریں گے۔ ڈیٹا فریمز "پرائمری کی" کی اصطلاح استعمال نہیں کرتے، تاہم آپ نوٹ کریں گے کہ وہ تقریباً اسی طرح کام کرتے ہیں۔ جب ہمارا شہروں کا ٹیبل تیار ہو گیا، تو آئیے بارش کا ڈیٹا ذخیرہ کریں۔ مکمل معلومات کو دہرانے کے بجائے، ہم ID کا استعمال کر سکتے ہیں۔ ہمیں یہ بھی یقینی بنانا چاہیے کہ نئے بنائے گئے ٹیبل میں بھی ایک *id* کالم ہو، کیونکہ تمام ٹیبلز میں ایک ID یا پرائمری کی ہونی چاہیے۔ ### بارش کا ٹیبل | rainfall_id | city_id | سال | مقدار | | ----------- | ------- | ---- | ------ | | 1 | 1 | 2018 | 1445 | | 2 | 1 | 2019 | 1874 | | 3 | 1 | 2020 | 1690 | | 4 | 2 | 2018 | 1779 | | 5 | 2 | 2019 | 1111 | | 6 | 2 | 2020 | 1683 | | 7 | 3 | 2018 | 1386 | | 8 | 3 | 2019 | 942 | | 9 | 3 | 2020 | 1176 | نوٹ کریں کہ نئے بنائے گئے **rainfall** ٹیبل میں **city_id** کالم موجود ہے۔ یہ کالم ان IDs کو رکھتا ہے جو **cities** ٹیبل میں موجود IDs کا حوالہ دیتے ہیں۔ تکنیکی ریلیشنل ڈیٹا اصطلاحات میں، اسے **foreign key** کہا جاتا ہے؛ یہ کسی دوسرے ٹیبل سے پرائمری کی ہے۔ آپ اسے صرف ایک حوالہ یا پوائنٹر کے طور پر سوچ سکتے ہیں۔ **city_id** 1 ٹوکیو کا حوالہ دیتا ہے۔ > [!NOTE] foreign key کو اکثر FK کے طور پر مختصر کیا جاتا ہے ## ڈیٹا بازیافت کرنا جب ہمارا ڈیٹا دو ٹیبلز میں تقسیم ہو گیا ہے، تو آپ سوچ سکتے ہیں کہ ہم اسے کیسے بازیافت کریں۔ اگر ہم MySQL، SQL Server یا Oracle جیسے ریلیشنل ڈیٹابیس کا استعمال کر رہے ہیں، تو ہم ایک زبان استعمال کر سکتے ہیں جسے Structured Query Language یا SQL کہا جاتا ہے۔ SQL (کبھی کبھار "سیکوئل" کے طور پر بولا جاتا ہے) ایک معیاری زبان ہے جو ریلیشنل ڈیٹابیس میں ڈیٹا کو بازیافت اور ترمیم کرنے کے لیے استعمال کی جاتی ہے۔ ڈیٹا بازیافت کرنے کے لیے آپ `SELECT` کمانڈ استعمال کرتے ہیں۔ بنیادی طور پر، آپ ان کالمز کو **منتخب** کرتے ہیں جنہیں آپ دیکھنا چاہتے ہیں، اور وہ **ٹیبل** بتاتے ہیں جس میں وہ موجود ہیں۔ اگر آپ صرف شہروں کے نام دکھانا چاہتے ہیں، تو آپ درج ذیل استعمال کر سکتے ہیں: ```sql SELECT city FROM cities; -- Output: -- Tokyo -- Atlanta -- Auckland ``` `SELECT` وہ جگہ ہے جہاں آپ کالمز کی فہرست دیتے ہیں، اور `FROM` وہ جگہ ہے جہاں آپ ٹیبلز کی فہرست دیتے ہیں۔ > [NOTE] SQL syntax کیس انسینسیٹو ہے، یعنی `select` اور `SELECT` ایک ہی معنی رکھتے ہیں۔ تاہم، آپ جس قسم کے ڈیٹابیس کا استعمال کر رہے ہیں اس پر منحصر ہے، کالمز اور ٹیبلز کیس سینسیٹو ہو سکتے ہیں۔ نتیجتاً، یہ ایک بہترین عمل ہے کہ پروگرامنگ میں ہر چیز کو کیس سینسیٹو سمجھا جائے۔ SQL کوئریز لکھتے وقت عام روایت یہ ہے کہ کی ورڈز کو تمام بڑے حروف میں لکھا جائے۔ اوپر دی گئی کوئری تمام شہروں کو دکھائے گی۔ آئیے تصور کریں کہ ہم صرف نیوزی لینڈ کے شہروں کو دکھانا چاہتے ہیں۔ ہمیں کسی قسم کے فلٹر کی ضرورت ہے۔ SQL میں اس کے لیے کی ورڈ `WHERE` ہے، یا "جہاں کچھ سچ ہو"۔ ```sql SELECT city FROM cities WHERE country = 'New Zealand'; -- Output: -- Auckland ``` ## ڈیٹا کو جوڑنا اب تک ہم نے ایک ہی ٹیبل سے ڈیٹا بازیافت کیا ہے۔ اب ہم **cities** اور **rainfall** دونوں سے ڈیٹا کو اکٹھا کرنا چاہتے ہیں۔ یہ انہیں *جوڑ* کر کیا جاتا ہے۔ آپ مؤثر طریقے سے دو ٹیبلز کے درمیان ایک سیون بنائیں گے، اور ہر ٹیبل کے ایک کالم سے ویلیوز کو ملائیں گے۔ ہمارے مثال میں، ہم **rainfall** کے **city_id** کالم کو **cities** کے **city_id** کالم کے ساتھ ملائیں گے۔ یہ بارش کی مقدار کو اس کے متعلقہ شہر کے ساتھ ملائے گا۔ جوائن کی قسم جو ہم انجام دیں گے اسے *inner* join کہا جاتا ہے، جس کا مطلب ہے کہ اگر کسی قطار کا دوسرے ٹیبل سے کوئی میل نہ ہو تو وہ ظاہر نہیں ہوگی۔ ہمارے معاملے میں ہر شہر کی بارش کا ڈیٹا موجود ہے، لہذا سب کچھ ظاہر ہوگا۔ آئیے 2019 کے لیے تمام شہروں کی بارش بازیافت کریں۔ ہم یہ مرحلہ وار کریں گے۔ پہلا مرحلہ ڈیٹا کو جوڑنا ہے، ان کالمز کو بتا کر جو سیون کے لیے استعمال ہوں گے - جیسا کہ پہلے نمایاں کیا گیا **city_id**۔ ```sql SELECT cities.city rainfall.amount FROM cities INNER JOIN rainfall ON cities.city_id = rainfall.city_id ``` ہم نے ان دو کالمز کو نمایاں کیا ہے جنہیں ہم چاہتے ہیں، اور یہ حقیقت کہ ہم ٹیبلز کو **city_id** کے ذریعے جوڑنا چاہتے ہیں۔ اب ہم `WHERE` اسٹیٹمنٹ شامل کر سکتے ہیں تاکہ صرف 2019 کا سال فلٹر ہو۔ ```sql SELECT cities.city rainfall.amount FROM cities INNER JOIN rainfall ON cities.city_id = rainfall.city_id WHERE rainfall.year = 2019 -- Output -- city | amount -- -------- | ------ -- Tokyo | 1874 -- Atlanta | 1111 -- Auckland | 942 ``` ## خلاصہ ریلیشنل ڈیٹابیسز کا مرکز معلومات کو متعدد ٹیبلز میں تقسیم کرنا ہے، جسے پھر ڈسپلے اور تجزیے کے لیے دوبارہ اکٹھا کیا جاتا ہے۔ یہ حساب کتاب کرنے اور ڈیٹا کو دیگر طریقوں سے جوڑنے میں اعلیٰ درجے کی لچک فراہم کرتا ہے۔ آپ نے ریلیشنل ڈیٹابیس کے بنیادی تصورات دیکھے، اور دو ٹیبلز کے درمیان جوائن کرنے کا طریقہ سیکھا۔ ## 🚀 چیلنج انٹرنیٹ پر متعدد ریلیشنل ڈیٹابیسز دستیاب ہیں۔ آپ ان ڈیٹابیسز کو دریافت کر سکتے ہیں اور اوپر سیکھی گئی مہارتوں کا استعمال کر سکتے ہیں۔ ## لیکچر کے بعد کا کوئز ## [لیکچر کے بعد کا کوئز](https://ff-quizzes.netlify.app/en/ds/quiz/9) ## جائزہ اور خود مطالعہ [Microsoft Learn](https://docs.microsoft.com/learn?WT.mc_id=academic-77958-bethanycheum) پر SQL اور ریلیشنل ڈیٹابیس کے تصورات کو دریافت کرنے کے لیے کئی وسائل دستیاب ہیں: - [ریلیشنل ڈیٹا کے تصورات کی وضاحت کریں](https://docs.microsoft.com//learn/modules/describe-concepts-of-relational-data?WT.mc_id=academic-77958-bethanycheum) - [Transact-SQL کے ساتھ کوئری کرنا شروع کریں](https://docs.microsoft.com//learn/paths/get-started-querying-with-transact-sql?WT.mc_id=academic-77958-bethanycheum) (Transact-SQL SQL کا ایک ورژن ہے) - [Microsoft Learn پر SQL مواد](https://docs.microsoft.com/learn/browse/?products=azure-sql-database%2Csql-server&expanded=azure&WT.mc_id=academic-77958-bethanycheum) ## اسائنمنٹ [اسائنمنٹ کا عنوان](assignment.md) --- **ڈسکلیمر**: یہ دستاویز AI ترجمہ سروس [Co-op Translator](https://github.com/Azure/co-op-translator) کا استعمال کرتے ہوئے ترجمہ کی گئی ہے۔ ہم درستگی کے لیے کوشش کرتے ہیں، لیکن براہ کرم آگاہ رہیں کہ خودکار ترجمے میں غلطیاں یا غیر درستیاں ہو سکتی ہیں۔ اصل دستاویز کو اس کی اصل زبان میں مستند ذریعہ سمجھا جانا چاہیے۔ اہم معلومات کے لیے، پیشہ ور انسانی ترجمہ کی سفارش کی جاتی ہے۔ ہم اس ترجمے کے استعمال سے پیدا ہونے والی کسی بھی غلط فہمی یا غلط تشریح کے ذمہ دار نہیں ہیں۔