You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
195 lines
22 KiB
195 lines
22 KiB
<!--
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
{
|
|
"original_hash": "9399d7b4767e75068f95ce5c660b285c",
|
|
"translation_date": "2025-09-06T07:27:10+00:00",
|
|
"source_file": "2-Working-With-Data/05-relational-databases/README.md",
|
|
"language_code": "mr"
|
|
}
|
|
-->
|
|
# डेटासह कार्य करणे: रिलेशनल डेटाबेस
|
|
|
|
| द्वारे स्केच नोट ](../../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 |
|
|
|
|
जरी यामुळे पंक्तींची पुनरावृत्ती टळते, तरी यामुळे इतर काही अडचणी निर्माण होतात. प्रत्येक वेळी नवीन वर्ष आल्यावर आपल्याला टेबलची रचना बदलावी लागेल. याशिवाय, आपला डेटा वाढत असताना वर्षे स्तंभ म्हणून ठेवणे मूल्ये शोधणे आणि गणना करणे कठीण करेल.
|
|
|
|
म्हणूनच आपल्याला एकाधिक टेबल्स आणि नातेसंबंधांची आवश्यकता आहे. आपला डेटा विभाजित करून आपण पुनरावृत्ती टाळू शकतो आणि आपल्या डेटासह काम करण्याच्या पद्धतीत अधिक लवचिकता मिळवू शकतो.
|
|
|
|
## नातेसंबंधांची संकल्पना
|
|
|
|
चला आपल्या डेटाकडे परत जाऊया आणि ते कसे विभाजित करायचे ते ठरवूया. आपल्याला शहरांचे नाव आणि देश साठवायचे आहे, म्हणून हे एका टेबलमध्ये चांगले काम करेल.
|
|
|
|
| शहर | देश |
|
|
| -------- | ------------- |
|
|
| टोकियो | जपान |
|
|
| अटलांटा | युनायटेड स्टेट्स |
|
|
| ऑकलंड | न्यूझीलंड |
|
|
|
|
पण पुढील टेबल तयार करण्यापूर्वी, आपल्याला प्रत्येक शहराचा संदर्भ कसा द्यायचा ते ठरवावे लागेल. आपल्याला काही प्रकारचा ओळखकर्ता, आयडी किंवा (तांत्रिक डेटाबेस संज्ञेत) प्राथमिक की आवश्यक आहे. प्राथमिक की म्हणजे टेबलमधील एका विशिष्ट पंक्तीची ओळख करण्यासाठी वापरलेले मूल्य. जरी हे स्वतःच्या मूल्यावर आधारित असू शकते (उदाहरणार्थ, आपण शहराचे नाव वापरू शकतो), तरी ते जवळजवळ नेहमीच एक संख्या किंवा इतर ओळखकर्ता असावे. आयडी कधीही बदलू नये कारण ते नातेसंबंध बिघडवेल. तुम्हाला बहुतेक प्रकरणांमध्ये प्राथमिक की किंवा आयडी एक स्वयंचलित क्रमांक असल्याचे आढळेल.
|
|
|
|
> ✅ प्राथमिक कीला वारंवार PK म्हणून संक्षेपित केले जाते
|
|
|
|
### शहर
|
|
|
|
| शहर_आयडी | शहर | देश |
|
|
| --------- | -------- | ------------- |
|
|
| 1 | टोकियो | जपान |
|
|
| 2 | अटलांटा | युनायटेड स्टेट्स |
|
|
| 3 | ऑकलंड | न्यूझीलंड |
|
|
|
|
> ✅ तुम्हाला लक्षात येईल की आम्ही या धड्यादरम्यान "आयडी" आणि "प्राथमिक की" या संज्ञा परस्पर बदलून वापरतो. येथे दिलेली संकल्पना डेटा फ्रेम्ससाठी लागू होते, ज्याचा तुम्ही नंतर अभ्यास कराल. डेटा फ्रेम्स "प्राथमिक की" ही संज्ञा वापरत नाहीत, परंतु तुम्हाला लक्षात येईल की त्या जवळजवळ त्याच प्रकारे वागतात.
|
|
|
|
आपले शहरांचे टेबल तयार झाल्यावर, चला पावसाचा डेटा साठवूया. शहराची संपूर्ण माहिती पुनरावृत्ती करण्याऐवजी, आपण आयडी वापरू शकतो. आपण नव्याने तयार केलेल्या टेबलमध्ये *आयडी* स्तंभ असल्याचे सुनिश्चित करावे, कारण सर्व टेबल्समध्ये आयडी किंवा प्राथमिक की असावी.
|
|
|
|
### पाऊस
|
|
|
|
| पाऊस_आयडी | शहर_आयडी | वर्ष | प्रमाण |
|
|
| ---------- | -------- | ---- | ------ |
|
|
| 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 |
|
|
|
|
नवीन तयार केलेल्या **पाऊस** टेबलमधील **शहर_आयडी** स्तंभ लक्षात घ्या. या स्तंभामध्ये **शहर** टेबलमधील आयडी संदर्भित करणारी मूल्ये आहेत. तांत्रिक रिलेशनल डेटा संज्ञेत, याला **परकीय की** म्हणतात; हे दुसऱ्या टेबलमधील प्राथमिक की आहे. तुम्ही याला फक्त संदर्भ किंवा पॉइंटर म्हणून विचार करू शकता. **शहर_आयडी** 1 टोकियोला संदर्भित करते.
|
|
|
|
> [!NOTE] परकीय कीला वारंवार FK म्हणून संक्षेपित केले जाते
|
|
|
|
## डेटा मिळवणे
|
|
|
|
आपला डेटा दोन टेबल्समध्ये विभाजित केल्यावर, तुम्हाला कदाचित आश्चर्य वाटेल की आपण तो कसा मिळवतो. जर आपण MySQL, SQL Server किंवा Oracle सारखा रिलेशनल डेटाबेस वापरत असाल, तर आपण Structured Query Language किंवा SQL नावाची भाषा वापरू शकतो. SQL (कधीकधी sequel असे उच्चारले जाते) ही रिलेशनल डेटाबेसमधील डेटा मिळवण्यासाठी आणि बदलण्यासाठी वापरली जाणारी मानक भाषा आहे.
|
|
|
|
डेटा मिळवण्यासाठी तुम्ही `SELECT` कमांड वापरता. त्याच्या मुख्य भागात, तुम्ही **select** करतो ते स्तंभ तुम्हाला **from** टेबलमध्ये पाहायचे असतात. जर तुम्हाला फक्त शहरांची नावे दाखवायची असतील, तर तुम्ही खालीलप्रमाणे करू शकता:
|
|
|
|
```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
|
|
```
|
|
|
|
## डेटा जोडणे
|
|
|
|
आतापर्यंत आपण एका टेबलमधून डेटा मिळवला आहे. आता आपण **शहर** आणि **पाऊस** या दोन्ही टेबल्समधील डेटा एकत्र आणू इच्छितो. हे त्यांना *जोडून* केले जाते. तुम्ही मूलत: दोन टेबल्समधील स्तंभांमध्ये सीम तयार कराल आणि प्रत्येक टेबलमधील स्तंभांमधील मूल्ये जुळवाल.
|
|
|
|
आपल्या उदाहरणात, आम्ही **पाऊस** मधील **शहर_आयडी** स्तंभ **शहर** मधील **शहर_आयडी** स्तंभाशी जुळवू. यामुळे पावसाचे मूल्य त्याच्या संबंधित शहराशी जुळेल. आपण करणार असलेला जोड हा *आंतर* जोड आहे, म्हणजे जर कोणत्याही पंक्ती दुसऱ्या टेबलमधील कोणत्याही गोष्टीशी जुळत नसतील तर त्या प्रदर्शित केल्या जाणार नाहीत. आपल्या प्रकरणात प्रत्येक शहराला पाऊस आहे, त्यामुळे सर्व काही प्रदर्शित होईल.
|
|
|
|
चला 2019 साठी सर्व शहरांचा पाऊस मिळवूया.
|
|
|
|
आपण हे टप्प्याटप्प्याने करूया. पहिला टप्पा म्हणजे **शहर_आयडी** स्तंभाद्वारे डेटा जोडणे.
|
|
|
|
```sql
|
|
SELECT cities.city
|
|
rainfall.amount
|
|
FROM cities
|
|
INNER JOIN rainfall ON cities.city_id = rainfall.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)
|
|
|
|
## पुनरावलोकन आणि स्व-अभ्यास
|
|
|
|
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) चा वापर करून भाषांतरित करण्यात आला आहे. आम्ही अचूकतेसाठी प्रयत्नशील असलो तरी, कृपया लक्षात घ्या की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेचा अभाव असू शकतो. मूळ भाषेतील मूळ दस्तऐवज हा अधिकृत स्रोत मानला जावा. महत्त्वाच्या माहितीसाठी व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराचा वापर केल्यामुळे उद्भवणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थासाठी आम्ही जबाबदार राहणार नाही. |