# डाटासँग काम गर्ने: रिलेशनल डाटाबेस | ](../../sketchnotes/05-RelationalData.png)| |:---:| | डाटासँग काम गर्ने: रिलेशनल डाटाबेस - _Sketchnote by [@nitya](https://twitter.com/nitya)_ | तपाईंले विगतमा जानकारी भण्डारण गर्न स्प्रेडशीट प्रयोग गर्नुभएको हुन सक्छ। तपाईंले पङ्क्ति र स्तम्भहरूको सेट राख्नुभएको थियो, जहाँ पङ्क्तिहरूले जानकारी (वा डाटा) समावेश गर्थे, र स्तम्भहरूले जानकारीको वर्णन गर्थे (कहिलेकाहीं मेटाडाटा भनिन्छ)। रिलेशनल डाटाबेस स्तम्भ र पङ्क्तिहरूको तालिकामा आधारित यो मुख्य सिद्धान्तमा निर्माण गरिएको छ, जसले तपाईंलाई जानकारी धेरै तालिकाहरूमा फैलाउन अनुमति दिन्छ। यसले तपाईंलाई जटिल डाटासँग काम गर्न, दोहोरोपनबाट बच्न, र डाटालाई अन्वेषण गर्ने तरिकामा लचिलोपन प्रदान गर्दछ। आउनुहोस् रिलेशनल डाटाबेसका अवधारणाहरू अन्वेषण गरौं। ## [पूर्व-व्याख्यान क्विज](https://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/8) ## यो सबै तालिकाबाट सुरु हुन्छ रिलेशनल डाटाबेसको केन्द्रमा तालिकाहरू हुन्छन्। स्प्रेडशीटको जस्तै, तालिका स्तम्भ र पङ्क्तिहरूको संग्रह हो। पङ्क्तिले हामी काम गर्न चाहेको डाटा वा जानकारी समावेश गर्दछ, जस्तै सहरको नाम वा वर्षा भएको मात्रा। स्तम्भहरूले तिनीहरूले भण्डारण गर्ने डाटाको वर्णन गर्छन्। आउनुहोस् सहरहरूको बारेमा जानकारी भण्डारण गर्न तालिका सुरु गरेर हाम्रो अन्वेषण सुरु गरौं। हामी तिनीहरूको नाम र देशबाट सुरु गर्न सक्छौं। तपाईं यसलाई निम्नानुसार तालिकामा भण्डारण गर्न सक्नुहुन्छ: | सहर | देश | | -------- | ------------- | | टोकियो | जापान | | एटलान्टा | संयुक्त राज्य | | अकल्यान्ड | न्यूजील्याण्ड | **सहर**, **देश**, र **जनसंख्या** स्तम्भ नामहरूले भण्डारण गरिएको डाटाको वर्णन गर्छन्, र प्रत्येक पङ्क्तिमा एक सहरको बारेमा जानकारी छ। ## एकल तालिका दृष्टिकोणको कमी संभावना छ, माथिको तालिका तपाईंलाई परिचित लाग्न सक्छ। आउनुहोस् हाम्रो बढ्दो डाटाबेसमा केही थप डाटा थपौं - वार्षिक वर्षा (मिलिमिटरमा)। हामी २०१८, २०१९, र २०२० वर्षहरूमा ध्यान केन्द्रित गर्नेछौं। यदि हामीले टोकियोको लागि थप्नुपर्‍यो भने, यो केही यस प्रकार देखिन सक्छ: | सहर | देश | वर्ष | मात्रा | | ----- | ----- | ---- | ------ | | टोकियो | जापान | २०२० | १६९० | | टोकियो | जापान | २०१९ | १८७४ | | टोकियो | जापान | २०१८ | १४४५ | हाम्रो तालिकामा तपाईंले के देख्नुभयो? तपाईंले देख्न सक्नुहुन्छ कि हामी सहरको नाम र देश बारम्बार दोहोर्याउँदैछौं। यसले धेरै भण्डारण लिन सक्छ, र धेरै हदसम्म अनावश्यक छ। आखिर, टोकियोको लागि हामीलाई चासोको एक मात्र नाम छ। ठिक छ, आउनुहोस् केही अर्को प्रयास गरौं। प्रत्येक वर्षको लागि नयाँ स्तम्भहरू थपौं: | सहर | देश | २०१८ | २०१९ | २०२० | | -------- | ------------- | ---- | ---- | ---- | | टोकियो | जापान | १४४५ | १८७४ | १६९० | | एटलान्टा | संयुक्त राज्य | १७७९ | ११११ | १६८३ | | अकल्यान्ड | न्यूजील्याण्ड | १३८६ | ९४२ | ११७६ | यसले पङ्क्ति दोहोरोपनबाट बचाउँछ, तर यसले केही अन्य चुनौतीहरू थप्छ। प्रत्येक पटक नयाँ वर्ष हुँदा हामीले हाम्रो तालिकाको संरचना परिमार्जन गर्नुपर्नेछ। साथै, हाम्रो डाटा बढ्दै जाँदा वर्षहरूलाई स्तम्भको रूपमा राख्दा मानहरू पुनःप्राप्ति र गणना गर्न कठिन हुनेछ। यही कारणले हामीलाई धेरै तालिकाहरू र सम्बन्धहरू आवश्यक छ। हाम्रो डाटालाई टुक्रा-टुक्रा गरेर हामी दोहोरोपनबाट बच्न सक्छौं र हाम्रो डाटासँग काम गर्ने तरिकामा बढी लचिलोपन प्राप्त गर्न सक्छौं। ## सम्बन्धहरूको अवधारणाहरू आउनुहोस् हाम्रो डाटामा फर्कौं र यसलाई कसरी विभाजन गर्ने निर्णय गरौं। हामीलाई थाहा छ कि हामी सहरहरूको नाम र देश भण्डारण गर्न चाहन्छौं, त्यसैले यो सम्भवतः एक तालिकामा राम्रोसँग काम गर्नेछ। | सहर | देश | | -------- | ------------- | | टोकियो | जापान | | एटलान्टा | संयुक्त राज्य | | अकल्यान्ड | न्यूजील्याण्ड | तर अर्को तालिका सिर्जना गर्नु अघि, हामीले प्रत्येक सहरलाई कसरी सन्दर्भ गर्ने निर्णय गर्नुपर्छ। हामीलाई कुनै प्रकारको पहिचानकर्ता, आईडी वा (प्राविधिक डाटाबेस सर्तमा) प्राथमिक कुञ्जी आवश्यक छ। प्राथमिक कुञ्जी एक मान हो जुन तालिकाको एक विशिष्ट पङ्क्ति पहिचान गर्न प्रयोग गरिन्छ। जबकि यो आफैंमा आधारित मान हुन सक्छ (उदाहरणका लागि, हामी सहरको नाम प्रयोग गर्न सक्छौं), यो लगभग सधैं एक नम्बर वा अन्य पहिचानकर्ता हुनुपर्छ। हामी चाहँदैनौं कि आईडी कहिल्यै परिवर्तन होस् किनकि यसले सम्बन्धलाई तोड्नेछ। तपाईंले अधिकांश अवस्थामा पाउनुहुनेछ कि प्राथमिक कुञ्जी वा आईडी स्वतः उत्पन्न गरिएको नम्बर हुनेछ। > ✅ प्राथमिक कुञ्जीलाई प्रायः PK भनेर छोट्याइन्छ ### सहरहरू | सहर_आईडी | सहर | देश | | --------- | -------- | ------------- | | १ | टोकियो | जापान | | २ | एटलान्टा | संयुक्त राज्य | | ३ | अकल्यान्ड | न्यूजील्याण्ड | > ✅ तपाईंले देख्नुहुनेछ कि हामी यस पाठको क्रममा "आईडी" र "प्राथमिक कुञ्जी" शब्दहरू परस्पर प्रयोग गर्छौं। यहाँका अवधारणाहरू डाटाफ्रेमहरूमा लागू हुन्छन्, जुन तपाईं पछि अन्वेषण गर्नुहुनेछ। डाटाफ्रेमहरूले "प्राथमिक कुञ्जी" को शब्दावली प्रयोग गर्दैनन्, तर तपाईंले देख्नुहुनेछ कि तिनीहरू धेरै हदसम्म उस्तै तरिकामा व्यवहार गर्छन्। हाम्रो सहरहरूको तालिका सिर्जना भएपछि, आउनुहोस् वर्षा भण्डारण गरौं। सहरको पूर्ण जानकारी दोहोर्याउने सट्टा, हामी आईडी प्रयोग गर्न सक्छौं। हामीले सुनिश्चित गर्नुपर्छ कि नयाँ सिर्जना गरिएको तालिकामा *आईडी* स्तम्भ पनि छ, किनकि सबै तालिकाहरूमा आईडी वा प्राथमिक कुञ्जी हुनुपर्छ। ### वर्षा | वर्षा_आईडी | सहर_आईडी | वर्ष | मात्रा | | ---------- | --------- | ---- | ------ | | १ | १ | २०१८ | १४४५ | | २ | १ | २०१९ | १८७४ | | ३ | १ | २०२० | १६९० | | ४ | २ | २०१८ | १७७९ | | ५ | २ | २०१९ | ११११ | | ६ | २ | २०२० | १६८३ | | ७ | ३ | २०१८ | १३८६ | | ८ | ३ | २०१९ | ९४२ | | ९ | ३ | २०२० | ११७६ | नयाँ सिर्जना गरिएको **वर्षा** तालिकाभित्रको **सहर_आईडी** स्तम्भलाई ध्यान दिनुहोस्। यो स्तम्भले **सहरहरू** तालिकाको आईडीहरूलाई सन्दर्भ गर्ने मानहरू समावेश गर्दछ। प्राविधिक रिलेशनल डाटा सर्तमा, यसलाई **विदेशी कुञ्जी** भनिन्छ; यो अर्को तालिकाको प्राथमिक कुञ्जी हो। तपाईं यसलाई सन्दर्भ वा सूचकको रूपमा सोच्न सक्नुहुन्छ। **सहर_आईडी** १ टोकियोलाई सन्दर्भ गर्दछ। > [!NOTE] विदेशी कुञ्जीलाई प्रायः FK भनेर छोट्याइन्छ ## डाटा पुनःप्राप्ति हाम्रो डाटा दुई तालिकामा विभाजित भएपछि, तपाईं सोच्न सक्नुहुन्छ कि हामी यसलाई कसरी पुनःप्राप्त गर्छौं। यदि हामी MySQL, SQL Server वा Oracle जस्ता रिलेशनल डाटाबेस प्रयोग गर्दैछौं भने, हामी Structured Query Language वा SQL नामक भाषा प्रयोग गर्न सक्छौं। SQL (कहिलेकाहीं "sequel" उच्चारण गरिन्छ) एक मानक भाषा हो जुन रिलेशनल डाटाबेसमा डाटा पुनःप्राप्ति र परिमार्जन गर्न प्रयोग गरिन्छ। डाटा पुनःप्राप्त गर्न तपाईंले `SELECT` आदेश प्रयोग गर्नुहुन्छ। यसको मुख्यमा, तपाईं **तपाईंले देख्न चाहनुभएको स्तम्भहरू चयन गर्नुहुन्छ** **तिनीहरू समावेश गरिएको तालिकाबाट**। यदि तपाईंले केवल सहरहरूको नाम प्रदर्शन गर्न चाहनुभयो भने, तपाईं निम्न प्रयोग गर्न सक्नुहुन्छ: ```sql SELECT city FROM cities; -- Output: -- Tokyo -- Atlanta -- Auckland ``` `SELECT` जहाँ तपाईं स्तम्भहरूको सूची बनाउनुहुन्छ, र `FROM` जहाँ तपाईं तालिकाहरूको सूची बनाउनुहुन्छ। > [NOTE] SQL वाक्यविन्यास केस-इन्सेन्सिटिभ हो, जसको अर्थ `select` र `SELECT` उस्तै हो। तर, तपाईंले प्रयोग गरिरहेको डाटाबेसको प्रकारमा निर्भर गर्दै स्तम्भहरू र तालिकाहरू केस-संवेदनशील हुन सक्छ। परिणामस्वरूप, प्रोग्रामिङमा सबै कुरा केस-संवेदनशील जस्तो व्यवहार गर्ने अभ्यास राम्रो हो। SQL क्वेरीहरू लेख्दा सामान्य परम्परा भनेको कीवर्डहरू सबै ठूला अक्षरमा लेख्नु हो। माथिको क्वेरीले सबै सहरहरू प्रदर्शन गर्नेछ। कल्पना गर्नुहोस् कि हामीले केवल न्यूजील्याण्डका सहरहरू प्रदर्शन गर्न चाह्यौं। हामीलाई कुनै प्रकारको फिल्टर आवश्यक छ। SQL कीवर्ड यसको लागि `WHERE` हो, वा "जहाँ केही सत्य छ।" ```sql SELECT city FROM cities WHERE country = 'New Zealand'; -- Output: -- Auckland ``` ## डाटा जोड्ने अहिलेसम्म हामीले एकल तालिकाबाट डाटा पुनःप्राप्त गरेका छौं। अब हामी **सहरहरू** र **वर्षा** दुवैबाट डाटालाई सँगै ल्याउन चाहन्छौं। यो तिनीहरूलाई *जोडेर* गरिन्छ। तपाईंले प्रभावकारी रूपमा दुई तालिकाहरू बीचमा एक सीम सिर्जना गर्नुहुनेछ, र प्रत्येक तालिकाको स्तम्भबाट मानहरू मिलाउनुहुनेछ। हाम्रो उदाहरणमा, हामी **वर्षा** मा रहेको **सहर_आईडी** स्तम्भलाई **सहरहरू** मा रहेको **सहर_आईडी** स्तम्भसँग मिलाउनेछौं। यसले वर्षाको मानलाई यसको सम्बन्धित सहरसँग मिलाउनेछ। हामीले गर्ने जोडको प्रकारलाई *इनर* जोड भनिन्छ, जसको अर्थ कुनै पनि पङ्क्तिहरूले अर्को तालिकाबाट केहीसँग मेल खाएन भने तिनीहरू प्रदर्शन हुने छैनन्। हाम्रो केसमा प्रत्येक सहरसँग वर्षा छ, त्यसैले सबै प्रदर्शन हुनेछ। आउनुहोस् २०१९ को वर्षाको डाटा सबै सहरहरूको लागि पुनःप्राप्त गरौं। हामी यो चरणहरूमा गर्नेछौं। पहिलो चरण भनेको **सहर_आईडी** स्तम्भद्वारा सीम संकेत गरेर डाटालाई सँगै जोड्नु हो। ```sql SELECT cities.city rainfall.amount FROM cities INNER JOIN rainfall ON cities.city_id = rainfall.city_id ``` हामीले चाहेको दुई स्तम्भहरू र **सहर_आईडी** द्वारा तालिकाहरूलाई सँगै जोड्न चाहेको तथ्यलाई हाइलाइट गरेका छौं। अब हामी `WHERE` स्टेटमेन्ट थप्न सक्छौं ताकि केवल २०१९ वर्ष मात्र फिल्टर होस्। ```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://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/9) ## समीक्षा र आत्म-अध्ययन SQL र रिलेशनल डाटाबेस अवधारणाहरूको अन्वेषण जारी राख्नका लागि [Microsoft Learn](https://docs.microsoft.com/learn?WT.mc_id=academic-77958-bethanycheum) मा धेरै स्रोतहरू उपलब्ध छन्। - [रिलेशनल डाटाको अवधारणाहरू वर्णन गर्नुहोस्](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) प्रयोग गरेर अनुवाद गरिएको छ। हामी शुद्धताको लागि प्रयास गर्छौं, तर कृपया ध्यान दिनुहोस् कि स्वचालित अनुवादहरूमा त्रुटि वा अशुद्धता हुन सक्छ। यसको मूल भाषामा रहेको मूल दस्तावेज़लाई आधिकारिक स्रोत मानिनुपर्छ। महत्वपूर्ण जानकारीको लागि, व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न हुने कुनै पनि गलतफहमी वा गलत व्याख्याको लागि हामी जिम्मेवार हुने छैनौं।