# डाटा संग काम गर्ने: रिलेशनल डाटाबेस | ](../../sketchnotes/05-RelationalData.png)| |:---:| | डाटा संग काम गर्ने: रिलेशनल डाटाबेस - _स्केच नोट [@nitya](https://twitter.com/nitya)_ | तपाईंले अघिल्लो समयमा जानकारी भण्डारण गर्न स्प्रेडशीट प्रयोग गर्नुभएको हुन सक्छ। तपाईंले पंक्तिहरू र स्तम्भहरूको सेट राख्नुभएको थियो, जहाँ पंक्तिहरूले जानकारी (वा डाटा) समावेश गर्थे, र स्तम्भहरूले जानकारीको वर्णन गर्थे (कहिलेकाहीं मेटाडाटा भनिन्छ)। रिलेशनल डाटाबेस स्तम्भहरू र पंक्तिहरूको तालिकामा आधारित यो मुख्य सिद्धान्तमा निर्माण गरिएको छ, जसले तपाईंलाई जानकारी धेरै तालिकाहरूमा फैलाउन अनुमति दिन्छ। यसले तपाईंलाई जटिल डाटासँग काम गर्न, नक्कल रोक्न, र डाटालाई अन्वेषण गर्ने तरिकामा लचिलोपन प्रदान गर्दछ। अब हामी रिलेशनल डाटाबेसका अवधारणाहरू अन्वेषण गरौं। ## [प्री-लेक्चर क्विज](https://ff-quizzes.netlify.app/en/ds/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://ff-quizzes.netlify.app/en/ds/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) प्रयोग गरेर अनुवाद गरिएको छ। हामी यथार्थताको लागि प्रयास गर्छौं, तर कृपया ध्यान दिनुहोस् कि स्वचालित अनुवादहरूमा त्रुटि वा अशुद्धता हुन सक्छ। यसको मूल भाषा मा रहेको मूल दस्तावेज़लाई आधिकारिक स्रोत मानिनुपर्छ। महत्वपूर्ण जानकारीको लागि, व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न हुने कुनै पनि गलतफहमी वा गलत व्याख्याको लागि हामी जिम्मेवार हुने छैनौं।