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.
175 lines
21 KiB
175 lines
21 KiB
<!--
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
{
|
|
"original_hash": "870a0086adbc313a8eea5489bdcb2522",
|
|
"translation_date": "2025-08-27T16:42:46+00:00",
|
|
"source_file": "2-Working-With-Data/05-relational-databases/README.md",
|
|
"language_code": "pa"
|
|
}
|
|
-->
|
|
# ਡਾਟਾ ਨਾਲ ਕੰਮ ਕਰਨਾ: ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ
|
|
|
|
| ਵੱਲੋਂ ਸਕੈਚਨੋਟ ](../../sketchnotes/05-RelationalData.png)|
|
|
|:---:|
|
|
| ਡਾਟਾ ਨਾਲ ਕੰਮ ਕਰਨਾ: ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ - _[@nitya](https://twitter.com/nitya) ਵੱਲੋਂ ਸਕੈਚਨੋਟ_ |
|
|
|
|
ਸਭ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕਰਨ ਲਈ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਰਤੀ ਹੋਵੇਗੀ। ਤੁਹਾਡੇ ਕੋਲ ਕਤਾਰਾਂ ਅਤੇ ਕਾਲਮਾਂ ਦਾ ਸੈੱਟ ਹੁੰਦਾ ਹੈ, ਜਿੱਥੇ ਕਤਾਰਾਂ ਵਿੱਚ ਜਾਣਕਾਰੀ (ਜਾਂ ਡਾਟਾ) ਹੁੰਦੀ ਹੈ, ਅਤੇ ਕਾਲਮ ਉਸ ਜਾਣਕਾਰੀ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹਨ (ਕਈ ਵਾਰ ਇਸਨੂੰ ਮੈਟਾਡੇਟਾ ਕਿਹਾ ਜਾਂਦਾ ਹੈ)। ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਕਾਲਮਾਂ ਅਤੇ ਕਤਾਰਾਂ ਦੇ ਇਸ ਮੁੱਖ ਸਿਧਾਂਤ 'ਤੇ ਬਣਿਆ ਹੁੰਦਾ ਹੈ, ਜੋ ਤੁਹਾਨੂੰ ਜਾਣਕਾਰੀ ਨੂੰ ਕਈ ਟੇਬਲਾਂ ਵਿੱਚ ਫੈਲਾਉਣ ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਜਟਿਲ ਡਾਟਾ ਨਾਲ ਕੰਮ ਕਰਨ, ਡੁਪਲੀਕੇਸ਼ਨ ਤੋਂ ਬਚਣ ਅਤੇ ਡਾਟਾ ਦੀ ਪੜਚੋਲ ਕਰਨ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਲਚੀਲਾਪਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਆਓ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੇ ਸਿਧਾਂਤਾਂ ਦੀ ਪੜਚੋਲ ਕਰੀਏ।
|
|
|
|
## [ਪ੍ਰੀ-ਲੈਕਚਰ ਕਵਿਜ਼](https://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/8)
|
|
|
|
## ਇਹ ਸਾਰਾ ਕੁਝ ਟੇਬਲਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ
|
|
|
|
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਟੇਬਲ ਹੁੰਦੇ ਹਨ। ਬਿਲਕੁਲ ਸਪ੍ਰੈਡਸ਼ੀਟ ਵਾਂਗ, ਇੱਕ ਟੇਬਲ ਕਾਲਮਾਂ ਅਤੇ ਕਤਾਰਾਂ ਦਾ ਸੰਗ੍ਰਹਿ ਹੁੰਦਾ ਹੈ। ਕਤਾਰ ਵਿੱਚ ਉਹ ਡਾਟਾ ਜਾਂ ਜਾਣਕਾਰੀ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨਾਲ ਅਸੀਂ ਕੰਮ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਜਿਵੇਂ ਕਿ ਸ਼ਹਿਰ ਦਾ ਨਾਮ ਜਾਂ ਵਰਖਾ ਦੀ ਮਾਤਰਾ। ਕਾਲਮ ਉਸ ਡਾਟਾ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹਨ ਜੋ ਉਹ ਸਟੋਰ ਕਰਦੇ ਹਨ।
|
|
|
|
ਆਓ ਸ਼ਹਿਰਾਂ ਬਾਰੇ ਜਾਣਕਾਰੀ ਸਟੋਰ ਕਰਨ ਲਈ ਇੱਕ ਟੇਬਲ ਸ਼ੁਰੂ ਕਰਕੇ ਆਪਣੀ ਪੜਚੋਲ ਸ਼ੁਰੂ ਕਰੀਏ। ਅਸੀਂ ਸ਼ਾਇਦ ਉਨ੍ਹਾਂ ਦੇ ਨਾਮ ਅਤੇ ਦੇਸ਼ ਨਾਲ ਸ਼ੁਰੂ ਕਰ ਸਕਦੇ ਹਾਂ। ਤੁਸੀਂ ਇਸਨੂੰ ਹੇਠਾਂ ਦਿੱਤੇ ਟੇਬਲ ਵਿੱਚ ਸਟੋਰ ਕਰ ਸਕਦੇ ਹੋ:
|
|
|
|
| ਸ਼ਹਿਰ | ਦੇਸ਼ |
|
|
| -------- | ------------- |
|
|
| ਟੋਕੀਓ | ਜਪਾਨ |
|
|
| ਐਟਲਾਂਟਾ | ਸੰਯੁਕਤ ਰਾਜ |
|
|
| ਆਕਲੈਂਡ | ਨਿਊਜ਼ੀਲੈਂਡ |
|
|
|
|
ਧਿਆਨ ਦਿਓ ਕਿ **ਸ਼ਹਿਰ**, **ਦੇਸ਼** ਅਤੇ **ਆਬਾਦੀ** ਦੇ ਕਾਲਮ ਨਾਮ ਸਟੋਰ ਕੀਤੇ ਜਾ ਰਹੇ ਡਾਟਾ ਨੂੰ ਵਰਣਨ ਕਰਦੇ ਹਨ, ਅਤੇ ਹਰ ਕਤਾਰ ਵਿੱਚ ਇੱਕ ਸ਼ਹਿਰ ਬਾਰੇ ਜਾਣਕਾਰੀ ਹੈ।
|
|
|
|
## ਇੱਕ ਟੇਬਲ ਪਹੁੰਚ ਦੇ ਘਾਟ
|
|
|
|
ਸਭ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਉਪਰੋਕਤ ਟੇਬਲ ਤੁਹਾਨੂੰ ਕਾਫ਼ੀ ਜਾਣੀ ਪਛਾਣੀ ਲੱਗਦੀ ਹੈ। ਆਓ ਆਪਣੀ ਨਵੀਂ ਬਣ ਰਹੀ ਡੇਟਾਬੇਸ ਵਿੱਚ ਕੁਝ ਹੋਰ ਡਾਟਾ ਸ਼ਾਮਲ ਕਰੀਏ - ਸਾਲਾਨਾ ਵਰਖਾ (ਮਿਲੀਮੀਟਰ ਵਿੱਚ)। ਅਸੀਂ 2018, 2019 ਅਤੇ 2020 ਦੇ ਸਾਲਾਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਾਂਗੇ। ਜੇ ਅਸੀਂ ਇਹ ਟੋਕੀਓ ਲਈ ਸ਼ਾਮਲ ਕਰੀਏ, ਤਾਂ ਇਹ ਕੁਝ ਇਸ ਤਰ੍ਹਾਂ ਲੱਗ ਸਕਦਾ ਹੈ:
|
|
|
|
| ਸ਼ਹਿਰ | ਦੇਸ਼ | ਸਾਲ | ਮਾਤਰਾ |
|
|
| ----- | ------- | ---- | ------ |
|
|
| ਟੋਕੀਓ | ਜਪਾਨ | 2020 | 1690 |
|
|
| ਟੋਕੀਓ | ਜਪਾਨ | 2019 | 1874 |
|
|
| ਟੋਕੀਓ | ਜਪਾਨ | 2018 | 1445 |
|
|
|
|
ਤੁਸੀਂ ਸਾਡੇ ਟੇਬਲ ਬਾਰੇ ਕੀ ਗੌਰ ਕੀਤਾ? ਤੁਸੀਂ ਸ਼ਾਇਦ ਗੌਰ ਕੀਤਾ ਹੋਵੇਗਾ ਕਿ ਅਸੀਂ ਸ਼ਹਿਰ ਅਤੇ ਦੇਸ਼ ਦੇ ਨਾਮ ਨੂੰ ਵਾਰ-ਵਾਰ ਦੁਹਰਾ ਰਹੇ ਹਾਂ। ਇਹ ਕਾਫ਼ੀ ਸਟੋਰੇਜ ਲੈ ਸਕਦਾ ਹੈ, ਅਤੇ ਬਹੁਤ ਹੱਦ ਤੱਕ ਬੇਲੋੜੀ ਹੈ। ਆਖਰਕਾਰ, ਟੋਕੀਓ ਦਾ ਸਿਰਫ ਇੱਕ ਹੀ ਨਾਮ ਹੈ ਜਿਸ ਵਿੱਚ ਸਾਨੂੰ ਦਿਲਚਸਪੀ ਹੈ।
|
|
|
|
ਠੀਕ ਹੈ, ਆਓ ਕੁਝ ਹੋਰ ਕੋਸ਼ਿਸ਼ ਕਰੀਏ। ਆਓ ਹਰ ਸਾਲ ਲਈ ਨਵੇਂ ਕਾਲਮ ਸ਼ਾਮਲ ਕਰੀਏ:
|
|
|
|
| ਸ਼ਹਿਰ | ਦੇਸ਼ | 2018 | 2019 | 2020 |
|
|
| -------- | ------------- | ---- | ---- | ---- |
|
|
| ਟੋਕੀਓ | ਜਪਾਨ | 1445 | 1874 | 1690 |
|
|
| ਐਟਲਾਂਟਾ | ਸੰਯੁਕਤ ਰਾਜ | 1779 | 1111 | 1683 |
|
|
| ਆਕਲੈਂਡ | ਨਿਊਜ਼ੀਲੈਂਡ | 1386 | 942 | 1176 |
|
|
|
|
ਜਦੋਂ ਕਿ ਇਹ ਕਤਾਰਾਂ ਦੇ ਦੁਹਰਾਵੇ ਤੋਂ ਬਚਦਾ ਹੈ, ਇਹ ਕੁਝ ਹੋਰ ਚੁਣੌਤੀਆਂ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ। ਸਾਨੂੰ ਹਰ ਵਾਰ ਇੱਕ ਨਵੇਂ ਸਾਲ ਦੇ ਆਉਣ 'ਤੇ ਆਪਣੇ ਟੇਬਲ ਦੀ ਬਣਤਰ ਨੂੰ ਬਦਲਣਾ ਪਵੇਗਾ। ਇਸਦੇ ਇਲਾਵਾ, ਜਿਵੇਂ ਜਿਵੇਂ ਸਾਡਾ ਡਾਟਾ ਵਧਦਾ ਹੈ, ਸਾਲਾਂ ਨੂੰ ਕਾਲਮਾਂ ਵਜੋਂ ਰੱਖਣਾ ਮੁੱਲਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਗਣਨਾ ਕਰਨ ਨੂੰ ਔਖਾ ਬਣਾ ਦੇਵੇਗਾ।
|
|
|
|
ਇਸ ਲਈ ਸਾਨੂੰ ਕਈ ਟੇਬਲਾਂ ਅਤੇ ਰਿਸ਼ਤਿਆਂ ਦੀ ਲੋੜ ਹੈ। ਸਾਡੇ ਡਾਟਾ ਨੂੰ ਵੱਖ-ਵੱਖ ਕਰਕੇ ਅਸੀਂ ਦੁਹਰਾਵੇ ਤੋਂ ਬਚ ਸਕਦੇ ਹਾਂ ਅਤੇ ਆਪਣੇ ਡਾਟਾ ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਤਰੀਕੇ ਵਿੱਚ ਹੋਰ ਲਚੀਲਾਪਨ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹਾਂ।
|
|
|
|
## ਰਿਸ਼ਤਿਆਂ ਦੇ ਸਿਧਾਂਤ
|
|
|
|
ਆਓ ਆਪਣੇ ਡਾਟਾ ਵੱਲ ਮੁੜ ਚੱਲੀਏ ਅਤੇ ਇਹ ਨਿਰਧਾਰਤ ਕਰੀਏ ਕਿ ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਵੰਡਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਸਾਨੂੰ ਪਤਾ ਹੈ ਕਿ ਅਸੀਂ ਆਪਣੇ ਸ਼ਹਿਰਾਂ ਲਈ ਨਾਮ ਅਤੇ ਦੇਸ਼ ਸਟੋਰ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ, ਇਸ ਲਈ ਇਹ ਸ਼ਾਇਦ ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਕਰੇਗਾ।
|
|
|
|
| ਸ਼ਹਿਰ | ਦੇਸ਼ |
|
|
| -------- | ------------- |
|
|
| ਟੋਕੀਓ | ਜਪਾਨ |
|
|
| ਐਟਲਾਂਟਾ | ਸੰਯੁਕਤ ਰਾਜ |
|
|
| ਆਕਲੈਂਡ | ਨਿਊਜ਼ੀਲੈਂਡ |
|
|
|
|
ਪਰ ਅਗਲਾ ਟੇਬਲ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਸਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਪਵੇਗਾ ਕਿ ਹਰ ਸ਼ਹਿਰ ਨੂੰ ਕਿਵੇਂ ਰਿਫਰੈਂਸ ਕਰਨਾ ਹੈ। ਸਾਨੂੰ ਕਿਸੇ ਕਿਸਮ ਦੇ ਪਛਾਣਕਰਤਾ, ID ਜਾਂ (ਤਕਨੀਕੀ ਡੇਟਾਬੇਸ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ) ਪ੍ਰਾਇਮਰੀ ਕੀ ਦੀ ਲੋੜ ਹੈ। ਪ੍ਰਾਇਮਰੀ ਕੀ ਇੱਕ ਮੁੱਲ ਹੈ ਜੋ ਇੱਕ ਟੇਬਲ ਵਿੱਚ ਇੱਕ ਖਾਸ ਕਤਾਰ ਦੀ ਪਛਾਣ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਜਦੋਂ ਕਿ ਇਹ ਖੁਦ ਇੱਕ ਮੁੱਲ 'ਤੇ ਆਧਾਰਿਤ ਹੋ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ ਅਸੀਂ ਸ਼ਹਿਰ ਦੇ ਨਾਮ ਨੂੰ ਵਰਤ ਸਕਦੇ ਹਾਂ), ਇਹ ਲਗਭਗ ਹਮੇਸ਼ਾ ਇੱਕ ਨੰਬਰ ਜਾਂ ਹੋਰ ਪਛਾਣਕਰਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਅਸੀਂ ਨਹੀਂ ਚਾਹੁੰਦੇ ਕਿ ID ਕਦੇ ਵੀ ਬਦਲੇ ਕਿਉਂਕਿ ਇਹ ਰਿਸ਼ਤੇ ਨੂੰ ਤੋੜ ਦੇਵੇਗਾ। ਜ਼ਿਆਦਾਤਰ ਮਾਮਲਿਆਂ ਵਿੱਚ ਤੁਸੀਂ ਪਾਓਗੇ ਕਿ ਪ੍ਰਾਇਮਰੀ ਕੀ ਜਾਂ ID ਇੱਕ ਆਟੋ-ਜਨਰੇਟ ਕੀਤੇ ਨੰਬਰ ਹੋਵੇਗਾ।
|
|
|
|
> ✅ ਪ੍ਰਾਇਮਰੀ ਕੀ ਨੂੰ ਅਕਸਰ PK ਦੇ ਰੂਪ ਵਿੱਚ ਸੰਖੇਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
|
|
|
|
### ਸ਼ਹਿਰਾਂ
|
|
|
|
| city_id | ਸ਼ਹਿਰ | ਦੇਸ਼ |
|
|
| ------- | -------- | ------------- |
|
|
| 1 | ਟੋਕੀਓ | ਜਪਾਨ |
|
|
| 2 | ਐਟਲਾਂਟਾ | ਸੰਯੁਕਤ ਰਾਜ |
|
|
| 3 | ਆਕਲੈਂਡ | ਨਿਊਜ਼ੀਲੈਂਡ |
|
|
|
|
> ✅ ਤੁਸੀਂ ਗੌਰ ਕਰੋਗੇ ਕਿ ਅਸੀਂ ਇਸ ਪਾਠ ਦੌਰਾਨ "id" ਅਤੇ "ਪ੍ਰਾਇਮਰੀ ਕੀ" ਸ਼ਬਦਾਂ ਨੂੰ ਪਰਸਪਰ ਵਰਤਦੇ ਹਾਂ। ਇੱਥੇ ਦਿੱਤੇ ਸਿਧਾਂਤ DataFrames 'ਤੇ ਵੀ ਲਾਗੂ ਹੁੰਦੇ ਹਨ, ਜਿਨ੍ਹਾਂ ਦੀ ਤੁਸੀਂ ਬਾਅਦ ਵਿੱਚ ਪੜਚੋਲ ਕਰੋਗੇ। DataFrames "ਪ੍ਰਾਇਮਰੀ ਕੀ" ਦੀ ਸ਼ਬਦਾਵਲੀ ਨਹੀਂ ਵਰਤਦੇ, ਪਰ ਤੁਸੀਂ ਗੌਰ ਕਰੋਗੇ ਕਿ ਉਹ ਬਹੁਤ ਹੱਦ ਤੱਕ ਇਸੇ ਤਰ੍ਹਾਂ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ।
|
|
|
|
ਸਾਡੇ ਸ਼ਹਿਰਾਂ ਦੇ ਟੇਬਲ ਨੂੰ ਬਣਾਉਣ ਦੇ ਨਾਲ, ਆਓ ਵਰਖਾ ਨੂੰ ਸਟੋਰ ਕਰੀਏ। ਪੂਰੀ ਜਾਣਕਾਰੀ ਨੂੰ ਦੁਹਰਾਉਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ ID ਨੂੰ ਵਰਤ ਸਕਦੇ ਹਾਂ। ਸਾਨੂੰ ਇਹ ਵੀ ਯਕੀਨੀ ਬਣਾਉਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਨਵੀਂ ਬਣੀ ਟੇਬਲ ਵਿੱਚ ਇੱਕ *id* ਕਾਲਮ ਵੀ ਹੋਵੇ, ਕਿਉਂਕਿ ਸਾਰੀਆਂ ਟੇਬਲਾਂ ਵਿੱਚ ਇੱਕ id ਜਾਂ ਪ੍ਰਾਇਮਰੀ ਕੀ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ।
|
|
|
|
### ਵਰਖਾ
|
|
|
|
| rainfall_id | city_id | ਸਾਲ | ਮਾਤਰਾ |
|
|
| ----------- | ------- | ---- | ------ |
|
|
| 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 |
|
|
|
|
ਨਵੀਂ ਬਣੀ **ਵਰਖਾ** ਟੇਬਲ ਦੇ ਅੰਦਰ **city_id** ਕਾਲਮ 'ਤੇ ਧਿਆਨ ਦਿਓ। ਇਸ ਕਾਲਮ ਵਿੱਚ ਉਹ ਮੁੱਲ ਹਨ ਜੋ **ਸ਼ਹਿਰਾਂ** ਟੇਬਲ ਵਿੱਚ ID ਨੂੰ ਰਿਫਰੈਂਸ ਕਰਦੇ ਹਨ। ਤਕਨੀਕੀ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾ ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ, ਇਸਨੂੰ **ਫਾਰਨ ਕੀ** ਕਿਹਾ ਜਾਂਦਾ ਹੈ; ਇਹ ਦੂਜੇ ਟੇਬਲ ਤੋਂ ਪ੍ਰਾਇਮਰੀ ਕੀ ਹੈ। ਤੁਸੀਂ ਇਸਨੂੰ ਸਿਰਫ ਇੱਕ ਰਿਫਰੈਂਸ ਜਾਂ ਪੌਇੰਟਰ ਵਜੋਂ ਸੋਚ ਸਕਦੇ ਹੋ। **city_id** 1 ਟੋਕੀਓ ਨੂੰ ਰਿਫਰੈਂਸ ਕਰਦਾ ਹੈ।
|
|
|
|
> [!NOTE] ਫਾਰਨ ਕੀ ਨੂੰ ਅਕਸਰ FK ਦੇ ਰੂਪ ਵਿੱਚ ਸੰਖੇਪ ਕੀਤਾ ਜਾਂਦਾ ਹੈ
|
|
|
|
## ਡਾਟਾ ਪ੍ਰਾਪਤ ਕਰਨਾ
|
|
|
|
ਸਾਡੇ ਡਾਟਾ ਨੂੰ ਦੋ ਟੇਬਲਾਂ ਵਿੱਚ ਵੰਡਣ ਦੇ ਨਾਲ, ਤੁਸੀਂ ਸੋਚ ਰਹੇ ਹੋ ਸਕਦੇ ਹੋ ਕਿ ਅਸੀਂ ਇਸਨੂੰ ਕਿਵੇਂ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਾਂ। ਜੇ ਅਸੀਂ MySQL, SQL Server ਜਾਂ Oracle ਵਰਗੇ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਾਂ, ਤਾਂ ਅਸੀਂ ਇੱਕ ਭਾਸ਼ਾ ਜਿਸਨੂੰ ਸਟ੍ਰਕਚਰਡ ਕਵੈਰੀ ਲੈਂਗਵੇਜ ਜਾਂ 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
|
|
```
|
|
|
|
## ਡਾਟਾ ਨੂੰ ਜੋੜਨਾ
|
|
|
|
ਹੁਣ ਤੱਕ ਅਸੀਂ ਸਿਰਫ ਇੱਕ ਟੇਬਲ ਤੋਂ ਡਾਟਾ ਪ੍ਰਾਪਤ ਕੀਤਾ ਹੈ। ਹੁਣ ਅਸੀਂ **ਸ਼ਹਿਰਾਂ** ਅਤੇ **ਵਰਖਾ** ਦੋਹਾਂ ਤੋਂ ਡਾਟਾ ਨੂੰ ਇਕੱਠਾ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਹ ਦੋਹਾਂ ਨੂੰ *ਜੋੜ ਕੇ* ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਦੋ ਟੇਬਲਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਸੀਮ ਬਣਾਉਂਦੇ ਹੋ, ਅਤੇ ਹਰ ਟੇਬਲ ਤੋਂ ਇੱਕ ਕਾਲਮ ਦੇ ਮੁੱਲਾਂ ਨੂੰ ਮੇਲ ਕਰਦੇ ਹੋ।
|
|
|
|
ਸਾਡੇ ਉਦਾਹਰਨ ਵਿੱਚ, ਅਸੀਂ **rainfall** ਵਿੱਚ **city_id** ਕਾਲਮ ਨੂੰ **cities** ਵਿੱਚ **city_id** ਕਾਲਮ ਨਾਲ ਮੇਲ ਕਰਾਂਗੇ। ਇਹ ਵਰਖਾ ਦੀ ਮਾਤਰਾ ਨੂੰ ਇਸਦੇ ਸੰਬੰਧਿਤ ਸ਼ਹਿਰ ਨਾਲ ਮੇਲ ਕਰੇਗਾ। ਜੋ ਜੋੜ ਅਸੀਂ ਕਰਾਂਗੇ, ਉਸਨੂੰ *ਅੰਦਰੂਨੀ* ਜੋੜ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਜਿਸਦਾ ਅਰਥ ਹੈ ਕਿ ਜੇਕਰ ਕੋਈ ਕਤਾਰਾਂ ਦੂਜੇ ਟੇਬਲ ਵਿੱਚ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੀਆਂ, ਤਾਂ ਉਹ ਦਿਖਾਈ ਨਹੀਂ ਜਾਣਗੀਆਂ। ਸਾਡੇ ਮਾਮਲੇ ਵਿੱਚ ਹਰ ਸ਼ਹਿਰ ਦੀ ਵਰਖਾ ਹੈ, ਇਸ ਲਈ ਸਭ ਕੁਝ ਦਿਖਾਇਆ ਜਾਵੇਗਾ।
|
|
|
|
ਆਓ ਸਾਰੇ ਸ਼ਹਿਰਾਂ ਲਈ 2019 ਦੀ ਵਰਖਾ ਪ੍ਰਾਪਤ ਕਰੀਏ।
|
|
|
|
ਅਸੀਂ ਇਹ ਕਦਮਾਂ ਵਿੱਚ ਕਰਾਂਗੇ। ਪਹਿਲਾ ਕਦਮ ਹੈ ਡਾਟਾ ਨੂੰ ਜੋੜਨਾ ਅਤੇ ਸੀਮ ਲਈ ਕਾਲਮਾਂ ਨੂੰ ਦਰਸਾਉਣਾ - ਜਿਵੇਂ ਕਿ ਪਹਿਲਾਂ ਹਾਈਲਾਈਟ ਕੀਤਾ ਗਿਆ ਸੀ, **city_id**।
|
|
|
|
```sql
|
|
SELECT cities.city
|
|
rainfall.amount
|
|
FROM cities
|
|
INNER JOIN rainfall ON cities.city_id = rainfall.city_id
|
|
```
|
|
|
|
ਅਸੀਂ ਦੋ ਕਾਲਮਾਂ ਅਤੇ ਟੇਬਲਾਂ ਨੂੰ **city_id** ਦੁਆਰਾ ਜੋੜਨ ਦੀ ਗੱਲ ਕੀਤੀ ਹੈ। ਹੁਣ ਅਸੀਂ ਸਿਰਫ 2019 ਦੇ ਸਾਲ ਨੂੰ ਫਿਲਟਰ ਕਰਨ ਲਈ `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
|
|
```
|
|
|
|
## ਸਾਰ
|
|
|
|
ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਕਈ ਟੇਬਲਾਂ ਵਿੱਚ ਜਾਣਕਾਰੀ ਨੂੰ ਵੰਡਣ 'ਤੇ ਕੇਂਦਰਿਤ ਹੁੰਦੇ ਹਨ, ਜਿਸਨੂੰ ਫਿਰ ਡਿਸਪਲੇਅ ਅਤੇ ਵਿਸ਼ਲੇਸ਼ਣ ਲਈ ਮੁੜ ਇਕੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਗਣਨਾ ਕਰਨ ਅਤੇ ਹੋਰ ਤਰੀਕਿਆਂ ਨਾਲ ਡਾਟਾ ਨੂੰ ਮੈਨਿਪੁਲੇਟ ਕਰਨ ਲਈ ਇੱਕ ਉੱਚ ਦਰਜੇ ਦੀ ਲਚੀਲਾਪਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਇੱਕ ਰਿਲੇਸ਼ਨਲ ਡੇਟਾਬੇਸ ਦੇ ਮੁੱਖ ਸਿਧਾਂਤਾਂ ਨੂੰ ਦੇਖਿਆ ਹੈ, ਅਤੇ ਦੋ ਟੇਬਲਾਂ ਦੇ ਵਿਚਕਾਰ ਇੱਕ
|
|
|
|
---
|
|
|
|
**ਅਸਵੀਕਾਰਨਾ**:
|
|
ਇਹ ਦਸਤਾਵੇਜ਼ AI ਅਨੁਵਾਦ ਸੇਵਾ [Co-op Translator](https://github.com/Azure/co-op-translator) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ। ਜਦੋਂ ਕਿ ਅਸੀਂ ਸਹੀ ਹੋਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹਾਂ, ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਸਵੈਚਾਲਿਤ ਅਨੁਵਾਦਾਂ ਵਿੱਚ ਗਲਤੀਆਂ ਜਾਂ ਅਸੁਚੱਜੇਪਣ ਹੋ ਸਕਦੇ ਹਨ। ਮੂਲ ਦਸਤਾਵੇਜ਼ ਨੂੰ ਇਸਦੀ ਮੂਲ ਭਾਸ਼ਾ ਵਿੱਚ ਅਧਿਕਾਰਤ ਸਰੋਤ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਜਾਣਕਾਰੀ ਲਈ, ਪੇਸ਼ੇਵਰ ਮਨੁੱਖੀ ਅਨੁਵਾਦ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਇਸ ਅਨੁਵਾਦ ਦੀ ਵਰਤੋਂ ਤੋਂ ਪੈਦਾ ਹੋਣ ਵਾਲੇ ਕਿਸੇ ਵੀ ਗਲਤਫਹਿਮੀ ਜਾਂ ਗਲਤ ਵਿਆਖਿਆ ਲਈ ਅਸੀਂ ਜ਼ਿੰਮੇਵਾਰ ਨਹੀਂ ਹਾਂ। |