![]() |
|---|
| डेटासह काम करणे: रिलेशनल डेटाबेस - Sketchnote by @nitya |
शक्यता आहे की तुम्ही पूर्वी माहिती साठवण्यासाठी स्प्रेडशीट वापरली असेल. तुमच्याकडे रकाने आणि स्तंभांचा संच होता, जिथे रकाने माहिती (किंवा डेटा) ठेवत होती, आणि स्तंभ माहितीचे वर्णन करत होते (कधी कधी मेटाडेटा म्हणतात). रिलेशनल डेटाबेस हा या स्तंभ आणि रकाने या तक्त्यांमधील मूलभूत तत्त्वावर आधारित असतो, ज्यामुळे तुम्हाला माहिती अनेक तक्त्यांमध्ये पसरवता येते. यामुळे तुम्ही अधिक जटिल डेटासह काम करू शकता, पुनरावृत्ती टाळू शकता, आणि डेटाचा शोध घेण्याच्या पद्धतीत लवचिकता मिळते. चला रिलेशनल डेटाबेसच्या संकल्पनांचा अभ्यास करूया.
रिलेशनल डेटाबेसच्या मूळात तक्ते असतात. स्प्रेडशीटप्रमाणे, तक्ता म्हणजे स्तंभ आणि रकान्यांचा संग्रह. रकान्यात आपल्याला काम करायची माहिती किंवा डेटा असतो, जसे की शहराचे नाव किंवा पर्जन्याचे प्रमाण. स्तंभ त्या डेटाचे वर्णन करतात जे ते साठवतात.
चला आपल्या शहरांबद्दल माहिती साठवण्यासाठी तक्ता तयार करून आपला अभ्यास सुरू करूया. आपण त्यांचे नाव आणि देश यांसह सुरू करू शकतो. तुम्ही हे खालीलप्रमाणे तक्त्यात साठवू शकता:
| City | Country |
|---|---|
| Tokyo | Japan |
| Atlanta | United States |
| Auckland | New Zealand |
लक्षात घ्या की city, country आणि population या स्तंभांच्या नावांनी साठवलेल्या डेटाचे वर्णन केले आहे, आणि प्रत्येक रकान्यात एका शहराची माहिती आहे.
शक्यता आहे की वरील तक्ता तुम्हाला परिचित वाटतो. चला आपल्या वाढत्या डेटाबेसमध्ये आणखी काही डेटा जोडूया - वार्षिक पर्जन्य (मिलिमीटरमध्ये). आपण 2018, 2019 आणि 2020 या वर्षांवर लक्ष केंद्रित करू. जर आपण टोकियोसाठी हे जोडले तर ते असे दिसू शकते:
| 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 |
पण पुढील तक्ता तयार करण्यापूर्वी, आपल्याला प्रत्येक शहराचा संदर्भ कसा द्यायचा हे ठरवावे लागेल. आपल्याला काही प्रकारचा ओळखपत्र, आयडी किंवा (तांत्रिक डेटाबेस भाषेत) प्राथमिक की आवश्यक आहे. प्राथमिक की म्हणजे तक्त्यातील एका विशिष्ट रकान्याची ओळख करण्यासाठी वापरली जाणारी किंमत. ही किंमत स्वतःवर आधारित असू शकते (उदाहरणार्थ, आपण शहराचे नाव वापरू शकतो), पण ती बहुतेक वेळा संख्या किंवा इतर ओळखपत्र असावी. आपण आयडी कधीही बदलू इच्छित नाही कारण त्यामुळे संबंध तुटू शकतो. बहुतेक प्रकरणांमध्ये प्राथमिक की किंवा आयडी स्वयंचलितपणे तयार होणारी संख्या असते.
✅ प्राथमिक कीला सहसा 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 किंवा प्राथमिक की असावी.
| 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 तक्त्यातील आयडींचा संदर्भ देतो. तांत्रिक रिलेशनल डेटाबेस भाषेत, याला foreign key म्हणतात; हा दुसऱ्या तक्त्याचा प्राथमिक की असतो. तुम्ही याला फक्त संदर्भ किंवा पॉइंटर म्हणून समजू शकता. city_id 1 म्हणजे टोकियोचा संदर्भ आहे.
Note
Foreign key ला सहसा FK असे संक्षिप्त केले जाते
आपल्या डेटाला दोन तक्त्यांमध्ये विभाजित केल्यावर, तुम्हाला कदाचित कसे प्राप्त करायचे आहे हे जाणून घ्यायचे असेल. जर आपण MySQL, SQL Server किंवा Oracle सारखा रिलेशनल डेटाबेस वापरत असाल, तर आपण Structured Query Language किंवा SQL नावाची भाषा वापरू शकता. SQL (कधी कधी sequel म्हणून उच्चारले जाते) ही रिलेशनल डेटाबेसमधून डेटा प्राप्त करण्यासाठी आणि बदलण्यासाठी वापरली जाणारी मानक भाषा आहे.
डेटा प्राप्त करण्यासाठी तुम्ही SELECT कमांड वापरता. त्याच्या मूळात, तुम्ही पाहू इच्छित स्तंभांची निवड करता आणि ते स्तंभ कोणत्या तक्त्यात आहेत ते सांगता. जर तुम्हाला फक्त शहरांची नावे दाखवायची असतील, तर तुम्ही खालीलप्रमाणे वापरू शकता:
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 या दोन्ही तक्त्यांमधील डेटा एकत्र आणू इच्छितो. हे जॉइन करून केले जाते. तुम्ही प्रत्यक्षात दोन तक्त्यांमध्ये एक सीम तयार कराल, आणि प्रत्येक तक्त्याच्या स्तंभातील मूल्ये जुळवून आणाल.
आपल्या उदाहरणात, आपण rainfall मधील city_id स्तंभ आणि cities मधील city_id स्तंभ जुळवू. यामुळे पर्जन्याचे मूल्य त्याच्या संबंधित शहराशी जुळेल. आपण करणार असलेला जॉइन हा inner जॉइन आहे, म्हणजे जर कोणत्याही रकान्याला दुसऱ्या तक्त्यात काहीही जुळत नसेल तर ते दाखवले जाणार नाही. आपल्या बाबतीत प्रत्येक शहराला पर्जन्य आहे, त्यामुळे सर्व काही दाखवले जाईल.
चला 2019 साठी सर्व शहरांचे पर्जन्य प्राप्त करूया.
आपण हे टप्प्याटप्प्याने करू. पहिला टप्पा म्हणजे डेटा जॉइन करणे, ज्यासाठी आपण आधी नमूद केलेल्या स्तंभांद्वारे - city_id - सीम दर्शवू.
SELECT cities.city
rainfall.amount
FROM cities
INNER JOIN rainfall ON cities.city_id = rainfall.city_idआपण हवे असलेले दोन स्तंभ आणि city_id द्वारे तक्ते जॉइन करायचे असल्याचे अधोरेखित केले आहे. आता आपण WHERE स्टेटमेंट जोडू शकतो जे फक्त 2019 वर्षासाठी फिल्टर करेल.
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 वापरून अनुवादित केला आहे. आम्ही अचूकतेसाठी प्रयत्न करतो, तरी कृपया लक्षात घ्या की स्वयंचलित अनुवादांमध्ये चुका किंवा अचूकतेची कमतरता असू शकते. मूळ दस्तऐवज त्याच्या स्थानिक भाषेत अधिकृत स्रोत मानला जावा. महत्त्वाच्या माहितीसाठी व्यावसायिक मानवी अनुवाद शिफारसीय आहे. या अनुवादाच्या वापरामुळे उद्भवलेल्या कोणत्याही गैरसमजुती किंवा चुकीच्या अर्थलागी आम्ही जबाबदार नाही.
