![]() |
|---|
| डाटासँग काम गर्ने: सम्बन्धित डाटाबेसहरू - Sketchnote by @nitya |
संभावना छ कि तपाईंले पहिले स्प्रेडशीट प्रयोग गरेर जानकारी भण्डारण गर्नुभएको छ। तपाईं सँग पङ्क्तिहरू र स्तम्भहरूको सेट थियो, जहाँ पङ्क्तिहरूले जानकारी (वा डाटा) समावेश गर्थे, र स्तम्भहरूले जानकारी वर्णन गर्थे (कहिलेकाहीं मेटाडाटा भनिन्छ)। सम्बन्धित डाटाबेस यो स्तम्भ र पङ्क्तिहरूको मूल सिद्धान्तमा आधारित हुन्छ, जसले तपाईंलाई धेरै तालिकाहरूमा जानकारी फैलाउन अनुमति दिन्छ। यसले तपाईंलाई जटिल डाटासँग काम गर्न, दोहोर्याइबाट बच्न, र डाटा अन्वेषण गर्ने तरिकामा लचिलोपन दिन्छ। आउनुहोस् सम्बन्धित डाटाबेसका अवधारणाहरू अन्वेषण गरौं।
सम्बन्धित डाटाबेसको मूलमा तालिकाहरू हुन्छन्। स्प्रेडशीट जस्तै, तालिका स्तम्भ र पङ्क्तिहरूको संग्रह हो। पङ्क्तिले हामीले काम गर्न चाहेको डाटा वा जानकारी समावेश गर्दछ, जस्तै शहरको नाम वा वर्षा परिमाण। स्तम्भहरूले तिनीहरूले भण्डारण गर्ने डाटालाई वर्णन गर्छन्।
हामी हाम्रो अन्वेषण सुरु गरौं र शहरहरूको बारेमा जानकारी भण्डारण गर्न तालिका सुरु गरौं। हामीले सायद तिनीहरूको नाम र देश राख्न सक्छौं। तपाईं यसलाई तलको तालिकामा भण्डारण गर्न सक्नुहुन्छ:
| City | Country |
|---|---|
| Tokyo | Japan |
| Atlanta | United States |
| Auckland | New Zealand |
ध्यान दिनुहोस् स्तम्भ नामहरू city, country र population ले भण्डारण गरिरहेको डाटालाई वर्णन गर्छन्, र प्रत्येक पङ्क्तिमा एउटा शहरको जानकारी हुन्छ।
संभावना छ, माथिको तालिका तपाईंलाई परिचित लाग्छ। अब हामी हाम्रो बढ्दो डाटाबेसमा थप डाटा थप्न सुरु गरौं - वार्षिक वर्षा (मिलिमिटरमा)। हामी २०१८, २०१९ र २०२० वर्षहरूमा केन्द्रित हुनेछौं। यदि हामीले यो टोकियोका लागि थप्यौं भने, यसले यसरी देखिन सक्छ:
| City | Country | Year | Amount |
|---|---|---|---|
| Tokyo | Japan | 2020 | 1690 |
| Tokyo | Japan | 2019 | 1874 |
| Tokyo | Japan | 2018 | 1445 |
तपाईंले हाम्रो तालिकामा के देख्नुभयो? तपाईंले देख्न सक्नुहुन्छ कि हामी शहरको नाम र देश बारम्बार दोहोर्याइरहेका छौं। यसले धेरै भण्डारण लिन सक्छ, र धेरैजसो आवश्यक छैन। आखिर, टोकियोको नाम त एउटै मात्र हो जुन हामीलाई चाहिन्छ।
ठीक छ, अर्को कुरा प्रयास गरौं। प्रत्येक वर्षका लागि नयाँ स्तम्भहरू थपौं:
| City | Country | 2018 | 2019 | 2020 |
|---|---|---|---|---|
| Tokyo | Japan | 1445 | 1874 | 1690 |
| Atlanta | United States | 1779 | 1111 | 1683 |
| Auckland | New Zealand | 1386 | 942 | 1176 |
यसले पङ्क्ति दोहोर्याइबाट बचाउँछ, तर केही अन्य चुनौतीहरू थप्छ। प्रत्येक नयाँ वर्ष आउँदा हामीले हाम्रो तालिकाको संरचना परिवर्तन गर्नुपर्नेछ। थप रूपमा, हाम्रो डाटा बढ्दै जाँदा वर्षहरूलाई स्तम्भको रूपमा राख्नुले मानहरू पुनःप्राप्ति र गणना गर्न गाह्रो बनाउँछ।
यसैले हामीलाई धेरै तालिकाहरू र सम्बन्धहरू आवश्यक पर्छ। हाम्रो डाटालाई टुक्र्याएर हामी दोहोर्याइबाट बच्न सक्छौं र डाटासँग काम गर्ने तरिकामा बढी लचिलोपन पाउन सक्छौं।
हामी हाम्रो डाटामा फर्केर हेर्नुहोस् र के कसरी विभाजन गर्ने निर्णय गरौं। हामीलाई थाहा छ हामी शहरहरूको नाम र देश भण्डारण गर्न चाहन्छौं, त्यसैले यो सम्भवतः एउटै तालिकामा सबैभन्दा राम्रो हुनेछ।
| City | Country |
|---|---|
| Tokyo | Japan |
| Atlanta | United States |
| Auckland | New Zealand |
तर अर्को तालिका बनाउनुअघि, हामीले प्रत्येक शहरलाई कसरी सन्दर्भ गर्ने थाहा पाउनुपर्छ। हामीलाई कुनै प्रकारको पहिचानकर्ता, ID वा (प्राविधिक डाटाबेस शब्दहरूमा) प्राथमिक कुञ्जी चाहिन्छ। प्राथमिक कुञ्जी एउटा मान हो जुन तालिकाको एउटा विशिष्ट पङ्क्तिलाई चिन्हित गर्न प्रयोग गरिन्छ। यो मानमा आधारित हुन सक्छ (उदाहरणका लागि शहरको नाम प्रयोग गर्न सकिन्छ), तर यो प्रायः संख्या वा अन्य पहिचानकर्ता हुनुपर्छ। हामी चाहँदैनौं कि id कहिल्यै परिवर्तन होस् किनकि यसले सम्बन्धलाई तोड्छ। अधिकांश अवस्थामा प्राथमिक कुञ्जी वा id स्वतः उत्पन्न हुने संख्या हुन्छ।
✅ प्राथमिक कुञ्जीलाई प्रायः PK भनेर छोट्याइन्छ
| city_id | City | Country |
|---|---|---|
| 1 | Tokyo | Japan |
| 2 | Atlanta | United States |
| 3 | Auckland | New Zealand |
✅ तपाईंले यस पाठमा "id" र "primary key" शब्दहरू विनिमययोग्य रूपमा प्रयोग भएको देख्नुहुनेछ। यहाँका अवधारणाहरू DataFrames मा पनि लागू हुन्छन्, जुन तपाईं पछि अन्वेषण गर्नुहुनेछ। DataFrames मा "primary key" शब्दावली प्रयोग हुँदैन, तर तपाईंले देख्नुहुनेछ कि तिनीहरू व्यवहारमा धेरै समान हुन्छन्।
हाम्रो cities तालिका बनाएपछि, वर्षा भण्डारण गरौं। शहरको पूर्ण जानकारी दोहोर्याउने सट्टा, हामी id प्रयोग गर्न सक्छौं। हामीले नयाँ तालिकामा पनि id स्तम्भ हुनु आवश्यक छ, किनकि सबै तालिकामा id वा प्राथमिक कुञ्जी हुनु पर्छ।
| rainfall_id | city_id | Year | Amount |
|---|---|---|---|
| 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 स्तम्भमा ध्यान दिनुहोस्। यस स्तम्भमा ती मानहरू छन् जुन cities तालिकामा रहेका IDs लाई सन्दर्भ गर्छन्। प्राविधिक सम्बन्धित डाटा शब्दहरूमा, यसलाई foreign key भनिन्छ; यो अर्को तालिकाबाट आएको प्राथमिक कुञ्जी हो। तपाईं यसलाई सन्दर्भ वा सूचकको रूपमा सोच्न सक्नुहुन्छ। city_id 1 ले टोकियोलाई सन्दर्भ गर्छ।
Note
Foreign key लाई प्रायः FK भनेर छोट्याइन्छ
हाम्रो डाटा दुई तालिकामा विभाजित भएपछि, तपाईं सोच्न सक्नुहुन्छ कि हामी कसरी यसलाई पुनःप्राप्त गर्छौं। यदि हामी MySQL, SQL Server वा Oracle जस्ता सम्बन्धित डाटाबेस प्रयोग गर्दैछौं भने, हामी Structured Query Language वा SQL नामक भाषा प्रयोग गर्न सक्छौं। SQL (कहिलेकाहीं sequel भनिन्छ) सम्बन्धित डाटाबेसमा डाटा पुनःप्राप्ति र संशोधन गर्न प्रयोग हुने मानक भाषा हो।
डाटा पुनःप्राप्त गर्न तपाईं SELECT कमाण्ड प्रयोग गर्नुहुन्छ। यसको मूलमा, तपाईंले हेर्न चाहेको स्तम्भहरू select गर्नुहुन्छ र ती स्तम्भहरू समावेश भएको तालिका from चयन गर्नुहुन्छ। यदि तपाईंले केवल शहरहरूको नाम देखाउन चाहनुभयो भने, तपाईंले तलको प्रयोग गर्न सक्नुहुन्छ:
SELECT city
FROM cities;
-- Output:
-- Tokyo
-- Atlanta
-- AucklandSELECT जहाँ तपाईं स्तम्भहरू सूचीबद्ध गर्नुहुन्छ, र FROM जहाँ तपाईं तालिकाहरू सूचीबद्ध गर्नुहुन्छ।
Note
SQL वाक्यविन्यास केस-इन्सेन्सिटिभ हुन्छ, जसको अर्थ select र SELECT एउटै हुन्छ। तर, तपाईंले प्रयोग गरिरहेको डाटाबेसको प्रकार अनुसार स्तम्भ र तालिका नाम केस-संवेदी हुन सक्छ। त्यसैले, प्रोग्रामिङमा सबै कुरा केस-संवेदी जस्तो व्यवहार गर्नु राम्रो अभ्यास हो। SQL क्वेरी लेख्दा सामान्य चलन भनेको कुञ्जीशब्दहरू सबै ठूलो अक्षरमा लेख्नु हो।
माथिको क्वेरीले सबै शहरहरू देखाउनेछ। कल्पना गरौं हामी केवल न्यूजिल्याण्डका शहरहरू देखाउन चाहन्छौं। हामीलाई कुनै प्रकारको फिल्टर चाहिन्छ। SQL कुञ्जीशब्द यसका लागि WHERE हो, जसको अर्थ "जहाँ केही सत्य हो"।
SELECT city
FROM cities
WHERE country = 'New Zealand';
-- Output:
-- Aucklandअहिलेसम्म हामीले एकल तालिकाबाट डाटा पुनःप्राप्त गरेका छौं। अब हामी दुवै cities र rainfall बाट डाटा सँगै ल्याउन चाहन्छौं। यसलाई joining गरेर गरिन्छ। तपाईंले दुई तालिकाबीच सीमाना सिर्जना गर्नुहुनेछ, र प्रत्येक तालिकाको स्तम्भबाट मानहरू मिलाउनुहुनेछ।
हाम्रो उदाहरणमा, हामी rainfall मा रहेको city_id स्तम्भलाई cities मा रहेको city_id स्तम्भसँग मिलाउनेछौं। यसले वर्षा मानलाई सम्बन्धित शहरसँग मिलाउनेछ। हामीले गर्ने जोइनको प्रकारलाई inner join भनिन्छ, जसको अर्थ यदि कुनै पङ्क्तिहरू अर्को तालिकासँग मेल खाँदैनन् भने तिनीहरू देखाइने छैनन्। हाम्रो अवस्थामा प्रत्येक शहरसँग वर्षा छ, त्यसैले सबै देखाइनेछ।
हामी सबै शहरहरूको २०१९ को वर्षा पुनःप्राप्त गरौं।
हामी यसलाई चरणहरूमा गर्नेछौं। पहिलो चरण हो डाटालाई जोड्नु, सीमाका लागि स्तम्भहरू संकेत गरेर - पहिले देखाइएको city_id।
SELECT cities.city
rainfall.amount
FROM cities
INNER JOIN rainfall ON cities.city_id = rainfall.city_idहामीले चाहेका दुई स्तम्भहरू हाइलाइट गरेका छौं, र हामीले तालिकाहरूलाई city_id द्वारा जोड्न चाहन्छौं। अब हामी WHERE वाक्यांश थपेर केवल २०१९ वर्ष फिल्टर गर्न सक्छौं।
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सम्बन्धित डाटाबेसहरू धेरै तालिकाहरूमा जानकारी विभाजन गर्नेमा केन्द्रित हुन्छन्, जुन पछि प्रदर्शन र विश्लेषणका लागि पुनः एकत्रित गरिन्छ। यसले गणना गर्न र अन्यथा डाटालाई हेरफेर गर्न उच्च लचिलोपन प्रदान गर्दछ। तपाईंले सम्बन्धित डाटाबेसका मूल अवधारणाहरू र दुई तालिकाबीच कसरी जोइन गर्ने देख्नुभयो।
इन्टरनेटमा धेरै सम्बन्धित डाटाबेसहरू उपलब्ध छन्। तपाईं माथि सिकेका सीपहरू प्रयोग गरेर डाटा अन्वेषण गर्न सक्नुहुन्छ।
Microsoft Learn मा SQL र सम्बन्धित डाटाबेस अवधारणाहरूको अन्वेषण जारी राख्नका लागि विभिन्न स्रोतहरू उपलब्ध छन्
- सम्बन्धित डाटाका अवधारणाहरू वर्णन गर्नुहोस्
- Transact-SQL सँग क्वेरी सुरु गर्नुहोस् (Transact-SQL SQL को एक संस्करण हो)
- Microsoft Learn मा SQL सामग्री
अस्वीकरण: यो दस्तावेज AI अनुवाद सेवा Co-op Translator प्रयोग गरी अनुवाद गरिएको हो। हामी शुद्धताका लागि प्रयासरत छौं, तर कृपया ध्यान दिनुहोस् कि स्वचालित अनुवादमा त्रुटि वा अशुद्धता हुन सक्छ। मूल दस्तावेज यसको मूल भाषामा आधिकारिक स्रोत मानिनु पर्छ। महत्वपूर्ण जानकारीका लागि व्यावसायिक मानव अनुवाद सिफारिस गरिन्छ। यस अनुवादको प्रयोगबाट उत्पन्न कुनै पनि गलतफहमी वा गलत व्याख्याका लागि हामी जिम्मेवार छैनौं।
