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
15 KiB
195 lines
15 KiB
<!--
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
{
|
|
"original_hash": "870a0086adbc313a8eea5489bdcb2522",
|
|
"translation_date": "2025-08-27T08:20:03+00:00",
|
|
"source_file": "2-Working-With-Data/05-relational-databases/README.md",
|
|
"language_code": "ar"
|
|
}
|
|
-->
|
|
# العمل مع البيانات: قواعد البيانات العلائقية
|
|
|
|
| ](../../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 أو (في مصطلحات قواعد البيانات التقنية) مفتاح أساسي. المفتاح الأساسي هو قيمة تُستخدم لتحديد صف معين في الجدول. بينما يمكن أن يكون ذلك بناءً على قيمة نفسها (يمكننا استخدام اسم المدينة، على سبيل المثال)، يجب أن يكون دائمًا تقريبًا رقمًا أو معرفًا آخر. لا نريد أن يتغير المعرف أبدًا لأنه سيؤدي إلى كسر العلاقة. ستجد في معظم الحالات أن المفتاح الأساسي أو المعرف سيكون رقمًا يتم إنشاؤه تلقائيًا.
|
|
|
|
> ✅ المفتاح الأساسي يُختصر غالبًا بـ PK
|
|
|
|
### المدن
|
|
|
|
| city_id | المدينة | الدولة |
|
|
| ------- | -------- | ------------- |
|
|
| 1 | طوكيو | اليابان |
|
|
| 2 | أتلانتا | الولايات المتحدة |
|
|
| 3 | أوكلاند | نيوزيلندا |
|
|
|
|
> ✅ ستلاحظ أننا نستخدم المصطلحين "معرف" و"مفتاح أساسي" بالتبادل خلال هذا الدرس. تنطبق المفاهيم هنا على DataFrames، والتي ستستكشفها لاحقًا. لا تستخدم DataFrames مصطلح "مفتاح أساسي"، ولكن ستلاحظ أنها تتصرف بنفس الطريقة تقريبًا.
|
|
|
|
مع إنشاء جدول المدن، دعونا نخزن بيانات الأمطار. بدلاً من تكرار المعلومات الكاملة عن المدينة، يمكننا استخدام المعرف. يجب أيضًا التأكد من أن الجدول الذي تم إنشاؤه حديثًا يحتوي على عمود *معرف* أيضًا، حيث يجب أن تحتوي جميع الجداول على معرف أو مفتاح أساسي.
|
|
|
|
### الأمطار
|
|
|
|
| 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** داخل جدول **الأمطار** الذي تم إنشاؤه حديثًا. يحتوي هذا العمود على قيم تشير إلى المعرفات في جدول **المدن**. في مصطلحات البيانات العلائقية التقنية، يُطلق على هذا اسم **مفتاح خارجي**؛ إنه مفتاح أساسي من جدول آخر. يمكنك التفكير فيه كمرجع أو مؤشر. **city_id** 1 يشير إلى طوكيو.
|
|
|
|
> [!NOTE] المفتاح الخارجي يُختصر غالبًا بـ FK
|
|
|
|
## استرجاع البيانات
|
|
|
|
مع فصل بياناتنا إلى جدولين، قد تتساءل كيف نسترجعها. إذا كنا نستخدم قاعدة بيانات علائقية مثل MySQL، SQL Server أو Oracle، يمكننا استخدام لغة تُسمى لغة الاستعلام الهيكلية أو SQL. SQL (تُنطق أحيانًا سيكويل) هي لغة قياسية تُستخدم لاسترجاع وتعديل البيانات في قاعدة بيانات علائقية.
|
|
|
|
لاسترجاع البيانات، تستخدم الأمر `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
|
|
```
|
|
|
|
## دمج البيانات
|
|
|
|
حتى الآن قمنا باسترجاع البيانات من جدول واحد. الآن نريد جمع البيانات من كل من **المدن** و**الأمطار**. يتم ذلك عن طريق *دمج* الجداول معًا. ستقوم فعليًا بإنشاء وصلة بين الجدولين، ومطابقة القيم من عمود من كل جدول.
|
|
|
|
في مثالنا، سنطابق العمود **city_id** في **الأمطار** مع العمود **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**. الآن يمكننا إضافة عبارة `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://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/9)
|
|
|
|
## المراجعة والدراسة الذاتية
|
|
|
|
هناك العديد من الموارد المتاحة على [Microsoft Learn](https://docs.microsoft.com/learn?WT.mc_id=academic-77958-bethanycheum) لمواصلة استكشافك لمفاهيم SQL وقواعد البيانات العلائقية
|
|
|
|
- [وصف مفاهيم البيانات العلائقية](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)
|
|
- [محتوى SQL على Microsoft Learn](https://docs.microsoft.com/learn/browse/?products=azure-sql-database%2Csql-server&expanded=azure&WT.mc_id=academic-77958-bethanycheum)
|
|
|
|
## الواجب
|
|
|
|
[عنوان الواجب](assignment.md)
|
|
|
|
---
|
|
|
|
**إخلاء المسؤولية**:
|
|
تمت ترجمة هذا المستند باستخدام خدمة الترجمة الآلية [Co-op Translator](https://github.com/Azure/co-op-translator). بينما نسعى لتحقيق الدقة، يرجى العلم أن الترجمات الآلية قد تحتوي على أخطاء أو معلومات غير دقيقة. يجب اعتبار المستند الأصلي بلغته الأصلية هو المصدر الموثوق. للحصول على معلومات حساسة أو هامة، يُوصى بالاستعانة بترجمة بشرية احترافية. نحن غير مسؤولين عن أي سوء فهم أو تفسيرات خاطئة تنشأ عن استخدام هذه الترجمة. |