Database-design-ar-hsoub-academy-v1.0

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫▪ جدول هاتف الموظف ‪( EmployeePhone‬معرف الموظ ف ‪ ،EID‬رقم اله اتف)‪ EID ،‬هن ا ه و‬
‫جزء من مفتاح رئيسي مركب‪ ،‬وهو مفتاح خارجي مرتبط بجدول الموظف السابق‪.‬‬

‫‪ 6.4‬السمات‬

‫يو َصف كل كيان بمجموعة من السمات ‪ ،attributes‬فمثاًل ‪ ،‬يمكن وصف كيان الموظف بالس مات التالي ة‪:‬‬
‫الاسم‪ ،‬أو العنوان‪ ،‬أو تاريخ الميلاد‪ ،‬أو الراتب‪ .‬تملك كل سمة اس ًما مح َّد ًدا‪ ،‬وترتب ط بكي ان مع َّين‪ ،‬وبمج ال من‬
‫القيم المس موحة ال تي يمكن أخ ذها‪ ،‬ولكن لا تُع َرض المعلوم ات ح ول مج ال الس مة في مخط ط الكي ان‬

‫والعلاقة ‪.ERD‬‬
‫تم َّثل كل سمة في مخطط الكيان والعلاقة الموضح في الشكل التالي تمثياًل بيضويًا مع اسم بداخله‪.‬‬

‫الشكل ‪ :6.2‬تمثيل ال ِسمات في نموذج العلاقات الكائني للبيانات‬

‫‪ 6.4.1‬أنواع السمات‬

‫هناك أنواع قليلة من السمات التي يجب أن تكون على دراية بها‪ ،‬ويجب ترك بعض ها كم ا هي‪ ،‬لكن يحت اج‬
‫بعضها الآخر إلى تعديل ليسهل تمثيلها في النموذج العلائقي ‪ ،relational model‬وسيناقش هذا القس م أن واع‬

‫السمات؛ أما لاح ًقا فسنناقش تعديل السمات لتلائم النموذج العلائقي بصورة صحيحة‪.‬‬

‫‪ 6.4.2‬السمات البسيطة‬

‫السمات البسيطة ‪ Simple attributes‬هي السمات المستمدة من مجالات القيمة ال َذري ة‪ ،‬ويطل ق عليه ا‬
‫أي ًضا اسم السمات وحيدة القيمة ‪ ،single-valued‬فمثاًل ‪ ،‬تجد في قاعدة بيان ات الش ركة ‪ COMPANY‬أن الاس م‬

‫والعمر هما نموذجان للسمات البسيطة‪.‬‬

‫‪ 6.4.3‬السمات المركبة‬

‫السمات المر َّكبة ‪ Composite attributes‬هي التي تتك ون من مجموع ة متسلس لة هرم ًي ا من الس مات‪،‬‬
‫فمثاًل ‪ ،‬قد يتكون العنوان باستخدام مثال قاعدة البيانات الشركة ‪ COMPANY‬والمو َّض ح في الش كل الت الي‪ ،‬من‬

‫‪51‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫رقم الشارع‪ ،‬واسم الشارع‪ ،‬واسم الحي‪ ،‬حيث يُم َّثل بالطريقة التالية‪ :‬العنوان = {‪" + 59‬ش ارع خال د بن الولي د"‬
‫‪" +‬حي القنوات"}‪.‬‬

‫الشكل ‪ :6.3‬مثال للسمات المركبة‬

‫‪ 6.4.4‬السمات متعددة القيم‬

‫السمات متعددة القيم ‪ Multivalued attributes‬هي ال تي تحم ل مجموع ًة من القيم لك ل كي ان‪ ،‬فمثاًل ‪،‬‬
‫يمكن أن تحمل سمة الدرجات العلمية ‪ degrees‬لموظف مع َّين في قاعدة بيان ات الش ركة ‪ COMPANY‬العدي د‬

‫من القيم‪ ،‬مثل‪ :‬دكتوراه ‪ ،PhD‬الجامعة العربية للعلوم‪ ،‬إجازة في العلوم ‪ BSc‬كما هو مو َّضح في الشكل التالي‪:‬‬

‫‪52‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫الشكل ‪ :6.4‬مثال على السمات متعددة القيم‬

‫‪ 6.4.5‬السمات المشتقة‬

‫السمات المشتقة ‪ Derived attributes‬هي سمات تحت وي على قيم محس وبة من س مات أخ رى‪ ،‬فمثاًل ‪،‬‬
‫يمكن اش تقاق العم ر في الش كل الت الي من ت اريخ الميلاد‪ ،‬يس مى ت اريخ الميلاد في ه ذه الحال ة س مة‬

‫مخزنة ‪ ،stored attribute‬وهي التي تُحفظ ماديًا لقاعدة البيانات‪.‬‬

‫الشكل ‪ :6.5‬مثال على ال ِسمات المشتقة‬

‫‪53‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫‪ 6.5‬المفاتيح‬

‫يُ َع ّد المفتاح ‪ key‬أحد القيود المهمة التي يجب وجودها في جميع الكيانات‪ ،‬وهو عبارة عن سمة أو مجموع ة‬
‫من السمات التي تُستخدم قيمها لتعريف كيان منفصل ‪ individual entity‬تعري ًفا فري ًدا في مجموعة الكيانات‪.‬‬

‫‪ 6.5.1‬أنواع المفاتيح‬

‫هناك عدة أنواع من المفاتيح‪ ،‬نذكر منها‪:‬‬

‫ا‪ .‬المفتاح المرشح‬

‫يُ َع ّد المفتاح المر َّشح ‪ candidate key‬مفتا ًحا بسي ًطا أو مر َّك ًبا‪ ،‬كما يكون فري ًدا وبس ي ًطا‪ ،‬وه و فري د لأن ه لا‬
‫يمكن أن يكون لصفين المفتاح المر َّشح نفسه في الجدول في أ ّي وقت‪ ،‬فمثاًل ‪ ،‬تكون المفاتيح المر َّشحة الممكنة‬
‫في كيان الموظف الموجود في قاعدة البيانات ‪ ،COMPANY‬والذي يتكون من السمات التالية‪ :‬معرِّف الموظف‪،‬‬
‫الاسم الأول‪ ،‬اسم العائلة‪ ،‬رقم التأمين الاجتماعي ‪ ،SIN‬العنوان‪ ،‬الهاتف‪ ،‬تاريخ الميلاد‪ ،‬ال راتب‪ ،‬مع رِّف القس م‪،‬‬

‫هي ما يلي‪:‬‬

‫• رقم التأمين الاجتماعي ‪ ،SIN‬أو معرف الموظف ‪.EID‬‬

‫• الاسم الأول واسم العائلة‪ ،‬بافتراض عدم وجود شخصين في الشركة لهما الاسم نفسه‪.‬‬

‫• اسم العائلة ومعرِّف القسم‪ ،‬بافتراض عدم عمل شخصين لهما اسم العائلة نفسه في القسم نفسه‪.‬‬

‫ب‪ .‬المفتاح المركب‬

‫يتك ون المفت اح الم ر َّكب ‪ composite key‬من س متين أو أك ثر‪ ،‬ويستحس ن الإبق اء على الح د الأدنى من‬
‫ال ِسمات فيه‪ .‬باستخدام المثال السابق نفسه‪ ،‬تكون المفاتيح المر َّكبة الممكنة هي‪:‬‬

‫• الاسم الأول واسم العائلة‪ ،‬بافتراض عدم وجود شخصين في الشركة لهما الاسم نفسه‪.‬‬

‫• اسم العائلة ومعرِّف القسم‪ ،‬بافتراض عدم عمل شخصين لهما اسم العائلة نفسه في القسم نفسه‪.‬‬

‫ج‪ .‬المفتاح الرئيسي‬

‫المفتاح الرئيسي ‪ primary key‬هو مفتاح مر َّشح ‪ candidate key‬يُح َّدد بواس طة مص مم قاع دة البيان ات‬
‫لاستخدامه على أساس آلية تعريف لمجموعة الكيانات بأكملها‪ ،‬كما يجب أن يُح ِّدد أسطر الجدول تحدي ًدا فري ًدا‪،‬‬

‫ولا يمكن تركه فار ًغا‪.‬‬

‫يُش ار إلى المفت اح الرئيس ي في نم وذج الكي ان والعلاق ة ‪ ER model‬عن طري ق وض ع خ ط تحت الس مة‬
‫التي تُم ِّثله‪.‬‬

‫‪54‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫• يُح َّدد مفتاح مر ِّشح بواس طة مص مم قاع دة البيان ات لتحدي د أس طر الج دول تحدي ًدا فري ًدا‪ ،‬ولا يمكن‬
‫تركه فار ًغا‪.‬‬

‫يُختار مفتاح مع ِّين من ِق َب ل مص مم قاع دة البيان ات لاس تخدامه على أس اس آلي ة تعري ف لمجموع ة‬ ‫•‬
‫الكيانات بأكملها‪ ،‬ويُشار إلى هذا المفتاح بالمفتاح الرئيس ي ‪ ،primary key‬كم ا يُش ار إلي ه عن طري ق‬

‫وضع خط تحت السمة المم ِّثلة له في نموذج الكيان والعلاقة ‪.ER model‬‬

‫إذا أخذنا المثال التالي‪ ،‬يتكون ك ل ص ف في ج دول الموظ ف من (‪ ،EID‬الاس م الأول‪ ،‬اس م العائل ة‪،SIN ،‬‬
‫العنوان‪ ،‬الهاتف‪ ،‬تاريخ الميلاد‪ ،‬الراتب‪ ،‬معرف القسم)‪ ،‬فإن المفتاح الرئيسي هو ‪.EID‬‬

‫د‪ .‬المفتاح الثانوي‬

‫المفتاح الثانوي ‪ secondary key‬هو سمة تُستخ َدم استخدا ًما صار ًما لأغراض الاس ترجاع‪ ،‬ويمكن أن يك ون‬
‫هذا المفتاح مرك ًبا من عدة سمات مثل أن يتكون من الهاتف واسم العائلة م ًعا‪.‬‬

‫ه‪ .‬المفتاح البديل‬

‫المفاتيح البديلة ‪ Alternate keys‬هي المفاتيح المر َّشحة التي لم تُستخ َدم على أساس مفتاح رئيسي‪.‬‬

‫و‪ .‬المفتاح الخارجي‬

‫يُ َع ّد المفت اح الخ ارجي ‪- foreign key‬أو ‪ FK‬اختص ا ًرا‪ -‬س م ًة موج ود ًة في ج دول مع َّين بحيث تش ير إلى‬
‫المفتاح الرئيسي في جدول آخر‪ ،‬أو يمكن تركه فار ًغا‪ ،‬ويجب أن تكون ك ل من المف اتيح الخارجي ة والرئيس ية من‬
‫ن وع البيان ات نفس ه‪ ،‬فمثاًل يُم ِّثل ُمع رِّف القس م ‪ DepartmentID‬المفت اح الخ ارجي ض من قاع دة بيان ات‬

‫الشركة ‪ ،COMPANY‬أي كما يلي‪:‬‬

‫• جدول الموظف ‪( Employee‬معرف الموظف ‪ ،EID‬الاسم الأول‪ ،‬اسم العائل ة‪ ،‬رقم الت أمين الاجتم اعي‬
‫‪ ،SIN‬العنوان‪ ،‬الهاتف‪ ،‬تاريخ الميلاد‪ ،‬الراتب‪ ،‬معرف القسم)‪.‬‬

‫‪ 6.5.2‬القيم الفارغة ‪Nulls‬‬

‫تُ َع ّد القيم ة الفارغ ة ‪ Null‬رم ًزا خا ًص ا ليس ل ه علاق ة بن وع بيان ات مح َّدد‪ ،‬مم ا يع ني أن ه إم ا غ ير‬
‫معروف ‪ unknown‬أو غير قابل للتطبيق ‪ ،inapplicable‬ولا يعني صفرًا أو فرا ًغا‪ ،‬ومن صفات هذه القيمة‪:‬‬

‫• لا توجد بيانات محددة لإدخالها‪.‬‬

‫• لا يمكن تواجدها في المفتاح الرئيسي‪.‬‬

‫• يجب تجنبها في جميع السمات الأخرى‪.‬‬

‫• يمكنها تمثيل ما يلي‪:‬‬

‫‪55‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫◦ قيمة سمة غير معروفة‪.‬‬
‫◦ قيمة سمة معروفة‪ ،‬ولكنها مفقودة‪.‬‬

‫◦ شرط "غير قابل للتطبيق"‪.‬‬
‫• يمكنها تسبيب العديد من المشاكل عند استخدام بعض الدوال‪ ،‬مثل‪ COUNT :‬و ‪ AVERAGE‬و ‪.SUM‬‬

‫• يمكنها تسبيب مشاكل منطقية عند ربط الجداول العلائقية ببعضها البعض‪.‬‬

‫تكون نتيجة عملية الموازنة القيمة الفارغة ‪ null‬عندما يكون أحد الحدود قيم ًة فارغ ًة ‪ ،null‬كما تكون النتيجة قيم ًة‬
‫فارغ ًة ‪ null‬في العمليات الحسابية إذا كان أحد الحدود قيم ًة فارغ ًة ‪ null‬باستثناء الدوال التي تتجاهل هذه القيمة‪.‬‬

‫‪ 6.5.3‬مثال لكيفية استخدام القيمة الفارغة ‪null‬‬

‫استخدم جدول الرواتب ‪ Salary_tbl‬التالي لمعرفة كيفية استخدام القيمة الفارغة ‪.null‬‬

‫‪emp#‬‬ ‫‪JopName‬‬ ‫‪Salary‬‬ ‫‪Commission‬‬
‫‪E10‬‬ ‫‪Sales‬‬ ‫‪12500‬‬ ‫‪32090‬‬
‫‪E11‬‬ ‫‪Null‬‬ ‫‪25000‬‬ ‫‪8000‬‬
‫‪E12‬‬ ‫‪Sales‬‬ ‫‪44000‬‬ ‫‪0‬‬
‫‪E13‬‬ ‫‪Sales‬‬ ‫‪44000‬‬ ‫‪Null‬‬

‫على أساس خطة أولى‪ ،‬ابدأ بإيجاد جميع الموظفين في عمود الموظ ف ‪ emp#‬في قس م المبيع ات ‪Sales‬‬
‫تحت عمود اسم الوظيفة ‪ ،jobName‬ممن تزيد رواتبهم ‪ salary‬مع عمولتهم ‪ commission‬عن ‪.30000‬‬

‫‪SELECT emp# FROM Salary_tbl‬‬
‫‪WHERE jobName = Sales AND‬‬
‫‪(commission + salary) > 30,000‬‬

‫يكون ناتج العملية أعلاه الموظ َفين ‪ ،E10‬و‪ ،E12‬إذ لا تتض من ه ذه النتيج ة الموظ ف ‪ E13‬بس بب القيم ة‬
‫الفارغة ‪ null‬في عمود العمولة ‪ ،commission‬حيث ستكون النتيجة القيمة الفارغة ‪ null‬عن د جم ع ال راتب م ع‬
‫العمولة‪ ،‬لذا سنحتاج إلى إلقاء نظرة على الحقول بصورة منفصلة للتأك د من تض مين الص ف ال ذي يحت وي على‬

‫القيمة الفارغة ‪ ،null‬كما هو مبين في الحل أدناه‪.‬‬

‫‪SELECT emp# FROM Salary_tbl‬‬
‫‪WHERE jobName = Sales AND‬‬

‫‪(commission > 30000 OR‬‬
‫‪salary > 30000 OR‬‬
‫‪(commission + salary) > 30,000‬‬

‫‪56‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫سيكون ناتج العملية أعلاه هو الموظ ِفين ‪ E10‬و ‪ E12‬و ‪.E13‬‬

‫‪ 6.5.4‬العلاقات‬

‫العلاقات ‪ Relationships‬هي الرابط الذي يرب ط الج داول ببعض ها البعض في قاع دة البيان ات‪ ،‬وتُس تخ َدم‬
‫لربط المعلومات ذات الصلة بين الجداول‪.‬‬

‫تعتمد قوة العلاقة ‪ Relationship strength‬على كيفية تعريف المفتاح الرئيسي للكيانات المترابطة‪ ،‬إذ تُ َع ّد‬
‫العلاقة ضعيفة ‪ ،weak‬أو غير محددة ‪ non-identifying‬إذا كان المفتاح الرئيسي للكيان المرتب ط لا يحت وي على‬

‫المفتاح الرئيسي للكيان الأب ‪ .parent entity‬وتتضمن قاعدة بيانات الشركة ‪ Company‬بعض الأمثلة التالية‪:‬‬
‫• جدول العميل ‪ Customer‬يحوي الحقلين التاليين‪:‬‬
‫◦ ‪ CustID‬رقم العميل‬
‫◦ ‪ CustName‬اسم العميل‬
‫• جدول الطلب ‪ Order‬يحوي الحقول التالية‪:‬‬
‫◦ ‪ OrderID‬رقم الطلب‬
‫◦ ‪ CustID‬رقم العميل‬
‫◦ ‪ Date‬تاريخ الطلب‬

‫يحتوي المفتاح الرئيسي للكيان المرتبط في العلاقة القوية أو المحددة على المفت اح الرئيس ي للكي ان الأب‪،‬‬
‫مثل التالي‪:‬‬

‫• جدول الدورة التدريبية ‪ Course‬يحوي الحقول التالي‪:‬‬
‫◦ ‪ CrsCode‬رمز الدورة‬

‫◦ ‪ DeptCode‬رمز القسم‬
‫◦ ‪ Description‬وصف الدورة‬
‫• جدول الصف ‪ Class‬يحوي الحقول التالية‪:‬‬

‫◦ ‪ CrsCode‬رمز الدورة‬
‫◦ ‪ Section‬القسم‬

‫◦ ‪ ClassTime‬وقت الصف ‪...‬إلخ‬

‫‪57‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫‪ 6.5.5‬أنواع العلاقات‬

‫هناك عدة أنواع من العلاقات منها‪:‬‬

‫ا‪ .‬علاقة واحد إلى متعدد‬

‫تُ َع ّد علاقة واح د إلى متع ِّدد ‪- one to many‬أو ‪ 1:M‬اختص ا ًرا‪ -‬الأس اس في أي تص ميم لقاع دة البيان ات‬
‫العلائقي ة‪ ،‬وتوج د في جمي ع بيئ ات قواع د البيان ات العلائقي ة‪ ،‬فمثاًل ‪ ،‬يحت وي القس م الواح د على العدي د من‬

‫الموظفين‪ ،‬ويو ِّضح الشكل التالي علاقة أحد هؤلاء الموظفين بالقسم‪.‬‬

‫الشكل ‪ :6.6‬علاقة واحد إلى متعدد‬

‫ب‪ .‬علاقة واحد إلى واحد‬

‫تُ َع ّد علاق ة واح د لواح د ‪- one to one‬أو ‪ 1:1‬اختص ا ًرا‪ -‬علاق ة كي ان واح د بكي ان واح د آخ ر فق ط‪،‬‬
‫والعكس صحيح‪.‬‬

‫يُ َع ّد هذا النوع من العلاقات نو ًعا ناد ًرا ج ًدا في تصميم قواعد البيانات العلائقية‪ ،‬ومن الممكن أن يشير وجود‬
‫ه ذه العلاق ة إلى انتم اء كي انَين بالفع ل إلى الج دول نفس ه‪ ،‬فمثاًل ‪ ،‬يك ون الموظ ف في قاع دة بيان ات‬

‫الشركة ‪ COMPANY‬مرتب ًطا بزوجة واحدة‪ ،‬وتكون الزوجة الواحدة مرتبط ًة بموظف واحد‪.‬‬

‫ج‪ .‬علاقة متعدد إلى متعدد‬

‫ضع في بالك النقاط التالية عند التعامل مع علاقة متع َِدد إلى متع َِدد ‪- many to many‬أو ‪ M:N‬اختصا ًرا‪:-‬‬
‫• لا يمكن تمثيلها بهذه الصورة ‪-‬أي متع َِدد إلى متع َِدد‪ -‬في النموذج العلائقي ‪.relational model‬‬
‫• يمكن تحويلها إلى علاقتين من النوع واحد إلى متع ِّدد‪.‬‬
‫• يمكن تنفيذها عن طريق كسرها لمجموعة علاقات من نوع واحد إلى متع ِّدد‪.‬‬

‫‪58‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫• تنطوي على تنفيذ كيانات مر َّكبة‪.‬‬

‫• تُن ِشئ علاقتين أو أكثر من النوع واحد إلى متع ِّدد‪.‬‬
‫• يجب أن يحتوي جدول الكيان المر َّكب على المفاتيح الرئيسية للجداول الأصلية على الأقل‪.‬‬

‫• يحتوي جدول الربط على تكرارات متعددة لقيم المفتاح الخارجي‪.‬‬

‫• قد تُس َند سمات إضافية حسب الحاجة‪.‬‬

‫يمكن ك تجنب المش اكل الموج ودة في علاق ة متع ِّدد إلى متع ِّدد عن طري ق إنش اء كي ان‬
‫م ر َّكب ‪ ،composite entity‬أو كي ان جس ري ‪ ،bridge entity‬فمثاًل ‪ ،‬يمكن للموظ ف العم ل في العدي د من‬
‫المشاريع‪ ،‬أو يمكن أن يعمل في المشروع الواح د العدي د من الم وظفين‪ ،‬اعتم ا ًدا على قواع د العم ل؛ أو يمكن‬

‫للطالب أخذ العديد من الدروس‪ ،‬كما يمكن للدرس الواحد أن يؤخذ بواسطة العديد من الطلاب‪.‬‬
‫يو ِّضح الشكل التالي جان ًبا آخ ًرا من علاقة ‪ ،M:N‬حيث يك ون للموظ ف العدي د من ت واريخ البداي ة المتعلِّق ة‬
‫بمشاريع مختلفة‪ ،‬لذلك نحتاج إلى ج دول رب ط ‪ JOIN‬بحيث يحت وي على مع رِّف الموظ ف ‪ ،EID‬والرم ز ‪،Code‬‬

‫وتاريخ البداية ‪.StartDate‬‬

‫الشكل ‪ :6.7‬للموظف العديد من تواريخ البدء المتعلقة بمشاريع مختلفة‬
‫إليك مثال على تعيين علاقة ثنائية من نوع متع ِّدد إلى متع ِّدد ‪:M:N‬‬

‫• ح ِّدد علاقتين لكل علاقة ثنائية من نوع متع ِّدد إلى متع ِّدد‪ ،‬ح ِّدد علاقتين‪.‬‬
‫• تمثل ‪ ،A‬و‪ B‬نو َعين من الكيانات المشاركة في ‪.R‬‬
‫• أنشئ علاقة جديدة ‪ S‬لتمثيل ‪.R‬‬

‫‪59‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫• تحت اج ‪ S‬أن تتض من المف اتيح الرئيس ية الخاص ة بـ ‪ ،A‬و‪ ،B‬حيث يمكن أن تك ون ه ذه م ًع ا المفت اح‬
‫الرئيس ي في الج دول ‪ ،S‬أو يمكن أن تض اف له ا س مة بس يطة أخ رى في الج دول الجدي د ‪ R‬لتك وين‬

‫المفتاح الرئيسي‪.‬‬

‫• تكون مجموعة المفاتيح الرئيسية لـ ‪ ،A‬و‪ B‬المفتاح الرئيسي لـ ‪.S‬‬

‫د‪ .‬العلاقة الأحادية ‪-‬أو التكرارية‪-‬‬

‫العلاقة الأحادية ‪- Unary relationship‬والتي تسمى العلاقة التكراري ة ‪ recursive‬أي ًض ا‪ -‬هي العلاق ة ال تي‬
‫توجد فيها علاقة بين تكرارات مجموعة الكيانات نفسها‪ ،‬ويكون في هذه العلاق ة المفتاح ان الرئيس ي والخ ارجي‬

‫متماثلَين لكنهما يمثلان كيانين لهما أدوار مختلفة‪ .‬تُ َع ّد مجموعة الكيان مجموع ًة من نوع مماثل من الكيانات‪.‬‬

‫الشكل ‪ :6.8‬العلاقات الأحادية (التكرارية)‬
‫يمكن إنشاء عمود منفصل بحيث يشير إلى المفت اح الرئيس ي لمجموع ة الكي ان نفس ها في بعض كيان ات‬

‫العلاقة الأحادية‪.‬‬

‫ه‪ .‬العلاقة الثلاثية ‪n-ary‬‬

‫العلاقة الثلاثية ‪ ternary relationship‬هي نوع من العلاقات يضمن إنشاء علاقة متع ِّدد إلى متع ِّدد بين ثلاثة‬
‫جداول‪ ،‬والشكل التالي هو مثال عن هذه العلاقة‪.‬‬

‫يشير مصطلح ‪ n-ary‬إلى جداول متع ِّددة في العلاقة‪ ،‬وتذ َّكر أ ّن ‪ N‬تكافئ ‪ many‬أي ‪.N = many‬‬
‫• لكل علاقة (‪ )n-ary‬حيث ‪ ،n > 2‬أنشئ جدواًل جدي ًدا لتمثيل تلك العلاقة‪.‬‬

‫• المفتاح الرئيسي للجدول الجديد هو مزيج من المفاتيح الرئيسية للكيانات المشاركة التي تمثل الج انب‬
‫المتع ِّدد ‪.N‬‬

‫• تملك جميع الكيانات المشاركة في معظم حالات علاقة ‪ n-ary‬الطرف المتع ِّدد من جانبها‪.‬‬

‫‪60‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫الشكل ‪ :6.9‬العلاقة الثلاثية‬

‫‪ 6.6‬مصطلحات أساسية‬

‫• المفتاح البديل ‪ :alternate key‬المفاتيح البديلة هي جميع المفاتيح المر َّشحة التي لم تُستخ َدم على‬
‫أساس مفتاح رئيسي‪.‬‬

‫• المفتاح المر َّشح ‪ :candidate key‬هو مفتاح بسيط أو مركب يتصف بأنه فريد أي لا يمكن أن يتكرر‬
‫وجوده في سطرين وأي ًضا أدنى ‪ minimal‬أي وجوده ضروري ومطلوب في كل الأعمدة المشتركة فيه‪.‬‬

‫• الكيانات المميزة ‪ :characteristic entities‬هي الكيانات التي توفر مزي ًدا من المعلومات حول‬
‫جدول آخر‪.‬‬

‫• السمات المركَّبة ‪ :composite attributes‬هي السمات التي تتكون من العديد من السمات‬
‫المتسلسلة هرم ًيا‪.‬‬

‫• المفتاح المركَّب ‪ :composite key‬يتك ّون المفتاح المركب من سمتين أو أكثر‪ ،‬ويستحسن الإبقاء على‬
‫الحد الأدنى من ال ِسمات فيه‪.‬‬

‫• الكيانات المعت ِمدة ‪ :dependent entities‬هي الكيانات التي تعتمد على جداول أخرى حتى يكون‬
‫لها معنى‪.‬‬

‫‪61‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫• السمات المشتقة ‪ :derived attributes‬هي التي تحتوي على قيم محسوبة من سمات أخرى‪.‬‬

‫• الكيانات المشتقة ‪ :derived entities‬انظر الكيانات المعت ِمدة‪.‬‬

‫• ‪ُ :EID‬معرِّف الموظف‪.‬‬
‫• الكيان ‪ :entity‬شيء ما أو كائن ما في العالم الحقيقي‪ ،‬وله وجود مستقل‪ ،‬ويمكن تمييزه عن الكائنات‬

‫الأخرى‪.‬‬
‫• نموذج الكيان والعلاقة لتمثيل البيانات أو ‪ :ER‬يسمى أي ًضا تخطيط الكيان والعلاقة‪ ،‬ويُم َّثل بواسطة‬

‫مخططات الكيان والعلاقة‪ ،‬والتي هي مناسبة تما ًما لنمذجة البيانات للاستخدام مع قواعد البيانات‪.‬‬
‫• تخطيط الكيان والعلاقة ‪ :entity relationship schema‬انظر إلى نموذج الكيان والعلاقة لتمثيل‬

‫البيانات‪.‬‬

‫• مجموعة الكيان ‪ :entity set‬تجميعة من الكيانات من النوع نفسه في وقت مع َّين‪.‬‬
‫• نوع الكيان ‪ :entity type‬تجميعة من الكيانات المتشابهة‪.‬‬

‫• المفتاح الخارجي ‪ foreign key‬أو ‪ :FK‬هو سمة موجودة في جدول مع َّين بحيث تشير إلى المفتاح‬
‫الرئيسي في جدول آخر‪ ،‬أو يمكن تركه فار ًغا ‪.null‬‬

‫• الكيان المستقل ‪ :independent entity‬الكيانات المستقلة هي اللبنات الرئيسية لبناء قواعد‬
‫البيانات‪ ،‬ولا يعتمد وجودها على أي كيانات أخرى‪.‬‬

‫• النواة ‪ :kernel‬انظر الكيان المستقل ‪.independent entity‬‬
‫• المفتاح ‪ :key‬سمة أو مجموعة من السمات التي تُستخدم قيمها لتعريف كيان منفصل ‪individual‬‬

‫‪ entity‬تعري ًفا فري ًدا في مجموعة الكيانات‪.‬‬

‫• السمات متعددة القيم ‪ :multivalued attributes‬هي التي لها مجموعة من القيم لكل كيان‪.‬‬

‫• ‪ :n-ary‬علاقة بين جداول متع ِّددة‪.‬‬
‫• القيمة الفارغة ‪ :null‬رمزًا خا ًصا ليس له علاقة بنوع بيانات مح َّدد‪ ،‬مما يعني أنه إما غير‬

‫معروف ‪ unknown‬أو غير قابل للتطبيق ‪ ،inapplicable‬ولا يعني صف ًرا أو فرا ًغا‬
‫• العلاقات ‪ :relationships‬هي الرابط الذي يربط الجداول ببعضها البعض في قاعدة البيانات‪،‬‬

‫وتُستخ َدم لربط المعلومات ذات الصلة بين الجداول‪.‬‬
‫• قوة العلاقة ‪ :relationship strength‬تُح َّدد قوة العلاقة استنا ًدا إلى كيفية تعريف المفتاح الرئيسي‬

‫للكيانات ذات الصلة‪.‬‬

‫‪62‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫• المفتاح الثانوي ‪ :secondary key‬هو سمة تُستخ َدم استخدا ًما صار ًما لأغراض الاسترجاع‪.‬‬
‫• السمات البسيطة ‪ :simple attributes‬مستمدة من مجالات القيم الذرية‪.‬‬
‫• ‪ :SIN‬رقم التأمين الاجتماعي‪.‬‬

‫• السمات ُأحادية القيمة ‪ :single-valued attributes‬انظر السمات البسيطة‪.‬‬
‫• السمة المخزنة ‪ :stored attribute‬هي السمة التي تُحفظ ماديًا في قاعدة البيانات‪.‬‬
‫• العلاقة الثلاثية ‪ :ternary relationship‬هي نوع من العلاقات التي تضمن إنشاء علاقة متع ِّدد إلى‬

‫متع ِّدد بين ثلاثة جداول‪.‬‬
‫• العلاقة الأحادية ‪ :unary relationship‬هي العلاقة التي توجد فيها علاقة بين تكرارات مجموعة‬

‫الكيانات نفسها وتدعى أي ًضا علاقة تكرارية ‪.recursive relationship‬‬

‫‪ 6.7‬تمارين‬

‫‪ .1‬ما المفهومان اللذان يعتمد عليهما نموذج الكيان والعلاقة ‪ER‬؟‬
‫‪ .2‬تتكون قاعدة البيانات التالية من جدولين‪ ،‬لذلك أجب على الأسئلة التالية عبر استخدامها‪:‬‬

‫◦ ح ِّدد المفتاح الرئيسي لكل جدول‪.‬‬
‫◦ ح ِّدد المفتاح الخارجي في الجدول ‪.PLAY‬‬
‫◦ ح ِّدد المفاتيح المر َّشحة في كلا الجدولين‪.‬‬

‫◦ ارسم نموذج الكيان والعلاقة ‪.ER‬‬
‫◦ هل يحقق الجدول ‪ PLAY‬سلام ًة مرجعي ًة؟ ول َم؟ أو ل َم لا؟‬

‫الجدول ‪:DIRECTOR‬‬

‫‪DIRNUM‬‬ ‫‪DIRNAME‬‬ ‫‪DIRDOB‬‬
‫‪100‬‬ ‫‪J_.Broadway‬‬ ‫‪01/08/39‬‬
‫‪101‬‬ ‫‪J.Namath‬‬ ‫‪11/12/48‬‬
‫‪102‬‬ ‫‪W.Blake‬‬ ‫‪06/15/44‬‬

‫‪63‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫الجدول ‪:PLAY‬‬

‫‪PLAYNO‬‬ ‫‪PLAYNAME‬‬ ‫‪DIRNUM‬‬
‫‪Cat on a cold bare roof‬‬ ‫‪102‬‬
‫‪1001‬‬ ‫‪Hold the mayo, pass the bread‬‬ ‫‪101‬‬
‫‪1002‬‬ ‫‪I never promised you coffee‬‬ ‫‪102‬‬
‫‪1003‬‬ ‫‪Silly putty goes to Texas‬‬ ‫‪100‬‬
‫‪1004‬‬ ‫‪See no sound, hear no sight‬‬ ‫‪101‬‬
‫‪1005‬‬

‫‪ .3‬عرف المصطلحات التالية‪ ،‬حيث قد تحتاج إلى البحث في الإنترنت‪.‬‬

‫◦ المخطط ‪.schema‬‬

‫◦ لغة المضيف ‪.host language‬‬

‫◦ اللغات الفرعية للبيانات ‪.data sublanguage‬‬

‫◦ لغة تعريف البيانات ‪.data definition language‬‬
‫◦ العلاقة اُألحادية ‪.unary relation‬‬

‫◦ المفتاح الخارجي ‪.foreign key‬‬

‫◦ العلاقة الافتراضية ‪.virtual relation‬‬

‫◦ الربط ‪.connectivity‬‬
‫◦ المفتاح المر َّكب ‪.composite key‬‬

‫◦ جداول الربط ‪.linking table‬‬

‫‪ .4‬تضمن قاعدة بيانات شركة ‪ PRE‬الجداول الثلاثة أدناه‪ ،‬لذلك أجب عن الأسئلة التالية مستخد ًما إياها‪:‬‬
‫◦ ح ِّدد المفتاح الرئيسي والمفتاح الخارجي في كل جدول‪.‬‬

‫◦ هل يحقق الجدول ‪ TRUCK‬سلام ًة مرجعي ًة؟ اشرح إجابتك‪.‬‬

‫◦ ما نوع العلاقة بين الجدولين ‪ ،TRUCK‬و‪.BASE‬‬

‫◦ كم عدد الكيانات في الجدول ‪.TRUCK‬‬
‫◦ ح ِّدد المفاتيح المر َّشحة في الجدول ‪.TRUCK‬‬

‫‪64‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫الجدول ‪:TRUCK‬‬

‫‪TNUM‬‬ ‫‪BASENUM‬‬ ‫‪TYPENUM‬‬ ‫‪TMILES‬‬ ‫‪TBOUGHT‬‬ ‫‪TSERIAL‬‬
‫‪1001‬‬ ‫‪501‬‬ ‫‪1‬‬ ‫‪5900.2‬‬ ‫‪11/08/90‬‬ ‫‪as-125‬‬
‫‪1002‬‬ ‫‪502‬‬ ‫‪2‬‬ ‫‪64523.9‬‬ ‫‪11/08/90‬‬ ‫‪ac-213‬‬
‫‪1003‬‬ ‫‪501‬‬ ‫‪2‬‬ ‫‪32116.0‬‬ ‫‪09/29/91‬‬ ‫‪ac-215‬‬
‫‪1004‬‬ ‫‪2‬‬ ‫‪3256.9‬‬ ‫‪01/14/92‬‬ ‫‪ac-315‬‬

‫الجدول ‪:BASE‬‬

‫‪BASENUM‬‬ ‫‪BASECITY‬‬ ‫‪BASESTATE‬‬ ‫‪BASEPHON‬‬ ‫‪BASE MGR‬‬
‫‪501‬‬ ‫‪Dallas‬‬ ‫‪TX‬‬ ‫‪893-9870‬‬ ‫‪J. Jones‬‬
‫‪502‬‬ ‫‪New York‬‬ ‫‪NY‬‬ ‫‪234-7689‬‬ ‫‪K. Lee‬‬

‫الجدول ‪:TYPE‬‬

‫‪TYPENUM‬‬ ‫‪TYPEDESC‬‬
‫‪1‬‬ ‫‪single box, double axle‬‬
‫‪2‬‬ ‫‪tandem trailer, single axle‬‬

‫‪ .5‬لنفترض أنك تستخدم قاعدة البيانات أدناه والمكونة من جدولين‪ ،‬أجب عن الأسئلة الآتية‪:‬‬

‫◦ ح ِّدد المفتاح الرئيسي في كل جدول‪.‬‬

‫◦ ح ِّدد المفتاح الخارجي في الجدول ‪.BookOrders‬‬
‫◦ هل هناك أي مفاتيح مر َّشحة في أي من الجدولين؟‬

‫◦ ارسم نموذج الكيان والعلاقة ‪.ER‬‬

‫◦ هل يحقق الجدول ‪ BookOrders‬السلامة المرجعية؟‬

‫◦ هل تحتوي الجداول على بيانات مكررة؟ ما هي؟‬

‫الجدول ‪:Customer‬‬

‫‪CustID‬‬ ‫‪CustName‬‬ ‫‪AccntNo‬‬
‫‪100‬‬ ‫‪Joe Smith‬‬
‫‪101‬‬ ‫‪Andy Blake‬‬ ‫‪010839‬‬
‫‪102‬‬ ‫‪Sue Brown‬‬ ‫‪111248‬‬
‫‪061544‬‬

‫‪65‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫الجدول ‪:BookOrders‬‬

‫‪OrderlD‬‬ ‫‪Title‬‬ ‫‪CustID‬‬ ‫‪Price‬‬
‫‪1001‬‬ ‫‪The Dark Tower‬‬ ‫‪102‬‬ ‫‪12.00‬‬
‫‪1002‬‬ ‫‪Incubus Dreams‬‬ ‫‪101‬‬ ‫‪19.99‬‬
‫‪1003‬‬ ‫‪Song of Susannah‬‬ ‫‪102‬‬ ‫‪23.00‬‬
‫‪1004‬‬ ‫‪The Time Traveler's Wife‬‬ ‫‪100‬‬ ‫‪21.00‬‬
‫‪1005‬‬ ‫‪The Dark Tower‬‬ ‫‪101‬‬ ‫‪12.00‬‬
‫‪1006‬‬ ‫‪Tanequil‬‬ ‫‪102‬‬ ‫‪15.00‬‬
‫‪1007‬‬ ‫‪Song of Susannah‬‬ ‫‪101‬‬ ‫‪23.00‬‬

‫‪ .6‬بالنظر إلى جدول الطالب الموضح في الشكل أدناه‪ ،‬اكتب قائم ة بجمي ع المف اتيح المر َّش حة الممكن ة‪،‬‬

‫واذكر سبب اختيارك لكل واحد من المفاتيح‪.‬‬

‫الشكل ‪ :6.10‬السؤال السادس‬
‫‪ .7‬أجب عن الأسئلة التالية مستخد ًما مخطط الكيان والعلاقة ‪ ERD‬لقاعدة بيانات المدرس ة الموض حة في‬

‫الشكل أدناه‪.‬‬
‫◦ ح ِّدد جميع الأنوية والكيانات المعت ِمدة والمميزة في مخطط الكيان والعلاقة ‪.ERD‬‬

‫◦ أي من الجداول لها علاقات ضعيفة‪ ،‬وأيها لديها علاقات قوية؟‬
‫◦ بالنظر إلى كل جدول من جداول قاع دة بيان ات المدرس ة‪ ،‬م ا هي الس مات ال تي يمكنه ا أن تأخ ذ‬

‫القيمة الفارغة ‪ ،Null‬ولماذا؟‬

‫‪66‬‬

‫تصميم قواعد البيانات‬ ‫نموذج الكيان والعلاقة ‪ ER‬وتمثيل البيانات‬

‫◦ ما هي الجداول التي ُأن ِشئت على أساس نتيجة لعلاقات متع ِّدد إلى متع ِّدد؟‬

‫الشكل ‪ :6.11‬السؤال السابع‬

‫‪67‬‬

‫‪ .7‬قواعد السلامة وقيودها لضمان‬

‫سلامة البيانات‬

‫تُ َع ّد القيود ‪ Constraints‬ميز ًة مهم ًة ج ًدا في النموذج العلائقي ‪ relational model‬الذي يدعم نظري ًة محدد ًة‬
‫للقيود ال ُمط َّبقة على ال ِس مات ‪ attributes‬أو الج داول ‪ ،tables‬كم ا تُ َع ّد ه ذه القي ود مفي د ًة بس بب س ماحها‬
‫لمصمم قواعد البيانات بتحديد دلالات ‪ semantics‬البيانات‪ ،‬فهذه القيود هي القواعد التي تجبر نظم إدارة قواعد‬
‫البيان ات ‪- Database management systems‬أو ‪ DBMSs‬اختص ا ًرا‪ -‬على التحق ق من تواف ق البيان ات مع‬

‫هذه الدلالات‪.‬‬

‫‪ 7.1‬سلامة النطاق ‪Domain Integrity‬‬

‫يُ َع ّد النطاق قي ًدا من قيود النموذج العلائقي‪ ،‬حيث يُق ّيد قيم السمات في العلاقة‪ ،‬لكن هناك دلالات واقعية‬
‫للبيانات التي لا يمكن تحديدها إذا اُستخ ِدمت مع قيود النطاق فقط‪ ،‬لذلك نحتاج إلى ط ر ٍق أك ثر تحدي ًدا لبي ان‬
‫قيم البيانات المسموح بها أو غير المسموح بها والتنس يق المناس ب لك ل س مة‪ ،‬فمثاًل ‪ ،‬يجب أن يك ون مع رّف‬
‫الموظ ف ‪- Employee ID‬أو ‪ EID‬اختص ا ًرا‪ -‬في قاع دة البيان ات فري ًدا‪ ،‬أو يجب أن يك ون ت اريخ ميلاد‬
‫الموظف ‪ Birthdate‬ضمن المجال [‪ ،]Jan 1, 1950 - Jan 1, 2000‬حيث تو َّفر هذه المعلومات ضمن تعليمات‬

‫منطقية تسمى قيود السلامة ‪ ،integrity constraints‬ويوجد عدة أنواع من قيود السلامة كما هو مو َّضح أدناه‪.‬‬

‫‪ 7.1.1‬سلامة الكيان ‪Entity integrity‬‬

‫يجب احتواء كل جدول على مفتاح رئيسي ‪ primary key‬لضمان سلامة الكي ان‪ ،‬ولا يمكن احت واء المفت اح‬
‫الرئيسي ‪ PK‬أو أي جزء منه على قيم فارغة ‪ ،null‬حيث لا يمكننا تحديد بعض الص فوف ‪ rows‬عن دما تك ون قيم‬
‫المفت اح الرئيس ي فارغ ة‪ ،‬فمثاًل ‪ ،‬لا يمكن أن يك ون اله اتف ‪ Phone‬في ج دول الموظ ف ‪ EMPLOYEE‬مفتا ًح ا‬

‫رئيس ًيا نظ ًرا لعدم امتلاك بعض الأشخاص أ ّي هاتف‪.‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫‪ 7.1.2‬السلامة المرجعية ‪Referential integrity‬‬

‫تتطلب السلامة المرجعية وجود مفتاح رئيسي مقابل للمفتاح الخارجي ‪ ،foreign key‬وإلا فيجب أن يك ون‬
‫فار ًغا‪ .‬ويُح َّدد هذا القيد بين جدولين أي الجدول الأب والجدول الابن؛ حيث يحا ِفظ على المطابق ة بين الص فوف‬

‫في هذين الجدولَين‪ ،‬وهذا يعني أن المرجع من ص ٍف في جدول إلى جدول آخر يجب أن يكون صالحًا‪.‬‬
‫فيما يلي مثال على قيود السلامة المرجعية في قاعدة بيانات العملاء‪/‬الطلب ات ‪ Customer/Order‬الخاص ة‬

‫بالشركة ‪:Company‬‬
‫• جدول العميل ‪ Customer‬يحوي الحقلين التاليين‪:‬‬

‫◦ ‪ CustID‬رقم العميل‬
‫◦ ‪ CustName‬اسم العميل‬
‫• جدول الطلب ‪ Order‬يحوي الحقول التالية‪:‬‬

‫◦ ‪ OrderID‬رقم الطلب‬
‫◦ ‪ CustID‬رقم العميل‬
‫◦ ‪ Date‬تاريخ الطلب‬
‫يجب فرض السلامة المرجعية لضمان عدم وج ود س جلات معزول ة أو يتيم ة ‪ ،orphan records‬فالس جل‬
‫المعزول هو السجل الذي تكون قيمة مفتاح ه الخ ارجي ‪ FK‬غ ير موج ودة في الكي ان المقاب ل ‪-‬أي الكي ان ال ذي‬
‫يحوي المفتاح الرئيسي ‪ ،PK‬وتذ ّكر أ ّن عملية الضم ‪ join‬تكون بين المفتا َحين الرئيسي ‪ PK‬والخارجي ‪.FK‬‬
‫ينص قيد السلامة المرجعي ة في المث ال الس ابق على وج وب تط ابق ‪ CustID‬في ج دول الطلب ات ‪Order‬‬
‫مع ‪ CustID‬صالح في جدول العملاء ‪.Customer‬‬
‫تملك معظم قواعد البيانات العلائقية س لامة مرجعي ة تص ريحية ‪ ،declarative referential integrity‬أي‬
‫يجري إعداد قيود السلامة المرجعية عند إنشاء الجداول‪.‬‬
‫فيما يلي مثال آخر على قاعدة بيانات صفوف دراسية‪/‬مقرَّرات ‪:Course/Class‬‬
‫• جدول الدورة التدريبية ‪ Course‬يحوي الحقول التالي‪:‬‬
‫◦ ‪ CrsCode‬رمز الدورة‬
‫◦ ‪ DeptCode‬رمز القسم‬
‫◦ ‪ Description‬وصف الدورة‬
‫• جدول الصف ‪ Class‬يحوي الحقول التالية‪:‬‬

‫‪69‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫◦ ‪ CrsCode‬رمز الدورة‬

‫◦ ‪ Section‬القسم‬

‫◦ ‪ ClassTime‬وقت الصف‬

‫ينص قيد السلامة المرجعية هنا على وجوب تطابق المفتاح الخارجي ‪ CrsCode‬في جدول ‪ Class‬مع مفتاح‬
‫رئيس ي ‪ CrsCode‬ص الح في ج دول ‪ ،Course‬حيث لا يكفي في ه ذه الحال ة أن تش كِّل الس متان ‪CrsCode‬‬

‫و ‪ Section‬في جدول ‪ Class‬المفتاح الرئيسي ‪ ،PK‬إذ يجب علينا فرض السلامة المرجعية‪.‬‬

‫يجب امتلاك المفتاح الرئيسي ‪ PK‬والمفتاح الخارجي ‪ FK‬أنواع البيانات نفسها‪ ،‬كما يجب أن يأتي ا من نفس‬
‫النط اق عن د إع داد الس لامة المرجعي ة‪ ،‬وإلا فلن يس مح نظ ام إدارة قاع دة البيان ات العلائقي ة ‪ RDBMS‬بعملية‬

‫الضم ‪.join‬‬

‫يُ َع ّد نظام ‪ RDBMS‬نظام قاعدة بيانات شائع‪ ،‬حيث يعتمد على النموذج العلائقي الذي قدمه إدجار كود (‪E.F.‬‬
‫‪ )Codd‬من مختبر أبحاث سان خوسيه (‪ )San Jose‬التابع لشركة ‪ ،IBM‬كما تُ َع ّد أنظمة قواعد البيانات العلائقي ة‬

‫أسهل في الاستخدام والفهم من أنظمة قواعد البيانات الأخرى‪.‬‬

‫‪ 7.1.3‬السلامة المرجعية في نظام مايكروسوفت أكسس‬

‫يج ري إع داد الس لامة المرجعي ة في نظ ام مايكروس وفت أكس س ‪ MS Access‬من خلال ض م المفت اح‬
‫الرئيسي ‪ PK‬الذي هو معرّف العميل ‪ CustID‬في جدول العملاء إلى معرّف العميل ‪ CustID‬في ج دول الطلب ات‬
‫‪ ،Order‬ويو ِّضح الشكل التالي طريقة عم ل ذل ك على شاش ة تحري ر العلاق ات ‪ Edit Relationships‬في نظ ام‬

‫مايكروسوفت أكسس‪:‬‬

‫‪70‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫‪ 7.1.4‬السلامة المرجعية في الإصدار ‪ Transact-SQL‬من لغة ‪SQL‬‬

‫تُض َبط الس لامة المرجعي ة في الإص دار ‪( Transact-SQL‬اختص ا ًرا ‪ )T-SQL‬المس تخدمة في‬
‫خادم ‪ MS SQL Server‬عند إنشاء جدول الطلبات ‪ Order‬باستخدام المفتاح الخارجي ‪ ،FK‬حيث تُظ ِهر التعليمات‬
‫المدرجة أدناه المفتاح الخارجي ‪ FK‬في جدول الطلبات ‪ Order‬الذي يك ون مرج ًع ا إلى المفت اح الرئيس ي ‪ PK‬في‬

‫جدول العملاء ‪:Customer‬‬

‫‪CREATE TABLE Customer‬‬
‫‪( CustID INTEGER PRIMARY KEY,‬‬
‫) )‪CustName CHAR(35‬‬

‫‪CREATE TABLE Orders‬‬
‫‪( OrderID INTEGER PRIMARY KEY,‬‬
‫‪CustID INTEGER REFERENCES Customer(CustID),‬‬
‫) ‪OrderDate DATETIME‬‬

‫‪ 7.1.5‬قواعد المفاتيح الخارجية‬

‫يمكن إضافة قواعد مفاتيح خارجية إضافية عند ضبط السلامة المرجعية مثل ما نفعله بالصفوف الأبناء ‪-‬في‬
‫جدول ‪ -Orders‬عندما يُح َذف أو يُغ َّير ‪-‬أي يُح َّدث‪ -‬السجل وهو جزء من الجدول الأب ‪ -Customer-‬وال ذي يمل ك‬
‫مفتا ًحا رئيس ًيا ‪ ،PK‬فمثاًل ‪ ،‬تَعرض نافذة تحرير العلاقات في ‪ MS Access‬في الشكل الس ابق خي ارين إض افيين‬
‫لقواعد المفتاح الخارجي ‪ ،FK‬هما‪ :‬التحديث المتسلسل أو التع اقبي ‪ ،Cascade Update‬والح ذف المتسلس ل‬
‫‪ ،Cascade Delete‬فإذا لم يُح َّدد هذان الخياران‪ ،‬فسيمنع النظام حذف أو تحديث قيم المفتاح الرئيس ي ‪ PK‬في‬
‫جدول الأب ‪-‬أي جدول العملاء ‪ -Customer‬في حالة وجود سجل ابن‪ ،‬فالس جل الابن ه و أي س جل م ع مفت اح‬

‫رئيسي ‪ PK‬مطابق‪.‬‬

‫يوجد خيار إضافي في بعض قواعد البيانات عند تحديد خيار الح ذف ويس مى ‪ ،Set to Null‬حيث يُح َذف‬
‫صف المفتاح الرئيسي ‪ PK‬في هذا الاختي ار‪ ،‬ولكن يُض َبط المفت اح الخ ارجي ‪ FK‬في الج دول الابن على القيم ة‬

‫الفارغة ‪ ،NULL‬فعلى الرغم من أ ّن هذا يؤدي إلى إنشاء صف يتيم‪ ،‬إلا أنه أمر مقبول‪.‬‬

‫‪ 7.2‬قيود المؤسسة ‪Enterprise Constraints‬‬

‫يشار إلى قي ود المؤسس ة أحيانً ا ب القيود الدلالي ة ‪ ،semantic constraints‬وهي قواع د إض افية يح ددها‬
‫المستخدمون أو مسؤولو قاعدة البيانات‪ ،‬كما يمكنها الاستناد إلى جداول متعددة‪ ،‬وفيما يلي بعض الأمثلة عنها‪:‬‬

‫• يمكن للصف الدراسي ‪ class‬ضم ثلاثين طال ًبا على أساس حد أقصى‪.‬‬

‫‪71‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫• يمكن للمد ّرس ‪ teacher‬تدريس أربعة صفوف في الفصل الواحد على أساس حد أقصى‪.‬‬
‫• لا يمكن للموظف ‪ employee‬المشاركة في أكثر من خمسة مشاريع‪.‬‬

‫• لا يمكن لراتب الموظف تجاوز راتب مديره‪.‬‬

‫‪ 7.3‬قواعد العمل ‪Business Rules‬‬

‫نحصل على قواعد العمل من المستخ ِدمين عن د جم ع المتطلب ات ‪ ،gathering requirements‬كم ا تُ َع ّد‬
‫عملية جمع المتطلبات عملي ًة مهم ًة للغاية‪ ،‬ويجب على المستخ ِدم أن يتحقق من نتائجها قبل بناء تصميم قاعدة‬
‫البيانات‪ ،‬فإذا كانت قواعد العمل غير صحيحة‪ ،‬فسيكون التصميم غير ص حيح‪ ،‬وفي النهاي ة لن يعم ل التط بيق‬

‫على النحو الذي تو ّقعه المستخ ِدمون‪ ،‬وفيما يلي بعض الأمثلة عن قواعد العمل‪ ،‬وهي‪:‬‬

‫• يمكن للمد ّرس تدريس طلاب متعددين‪.‬‬
‫• يمكن للصف الدراسي امتلاك ‪ 35‬طال ًبا على أساس حد أقصى‪.‬‬
‫• يمكن تدريس ال ُمقرَّر ‪ course‬عدة مرات‪ ،‬ولكن يدرِّسه مدرِّس واحد فقط‪.‬‬

‫• لا يد ّرس جميع المدرِّسين صفو ًفا دراسية‪.‬‬

‫‪ 7.3.1‬تعددية العلاقة ‪ Cardinality‬والارتباط ‪connectivity‬‬

‫تُستخ َدم قواعد العمل لتحديد عددية العلاقة والارتباط‪ ،‬حيث تصف عددية العلاقة ‪ Cardinality‬العلاق ة بين‬
‫جدولي بيانات من خلال التعبير عن الحد الأدنى والحد الأقصى لعدد مرات حدوث الكيان المرتبط بح دوث كي ا ٍن‬
‫آخر ذي صلة‪ ،‬ويم ّكنك الشكل التالي من رؤي ة أن عددي ة العلاق ة مم َّثل ة من خلال العلام ات الداخلي ة على رم ز‬

‫العلاقة‪ ،‬حيث تكون درجة العلاقة ‪ Cardinality‬هي ‪ 0‬على اليمين بينما هي ‪ 1‬على اليسار‪.‬‬

‫‪72‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫يمثل الرمز الخارجي لرمز العلاقة الارتباط ‪ Connectivity‬بين الجدولين‪ ،‬فالارتب اط ه و العلاق ة بين ج دولين‬
‫مثل علاقة واحد إلى واحد ‪ ،one to one‬أو واحد إلى متعدد ‪one to many‬؛ والمرة الوحي دة ال تي يك ون فيه ا‬

‫الارتباط صفرًا هي عندما يكون للمفتاح الخارجي ‪ FK‬قيمة فارغة ‪.null‬‬
‫يوجد ثلاثة خيارات للعلاقة بين هذه الكيانات عندما يتعلق الأمر بالمشاركة‪ ،‬وهي‪ ،0 :‬أو ‪ ،1‬أو متعدد ‪،many‬‬
‫فمثاًل ‪ ،‬قيمة الارتب اط ‪ Connectivity‬هي ‪ 1‬في الش كل الس ابق على الج انب الخ ارجي الأيس ر من ه ذا الخ ط‪،‬‬

‫ومتعدد على الجانب الخارجي الأيمن‪.‬‬
‫يظهر الشكل التالي الرمز الذي يمثل علاقة واحد إلى متعدد ‪:one to many‬‬

‫يعرض الشكل الآتي كاًل من العلامات الداخلية ‪-‬التي تمثل عددية العلاقة ‪ -Cardinality‬والعلامات الخارجي ة‬
‫‪-‬التي تمثل الارتباط ‪ ،-Connectivity‬إذ يُقرأ الجانب الأيسر من هذا الرمز على أن الحد الأدنى ‪ 1‬والحد الأقصى ‪،1‬‬

‫بينما يُقرأ الجانب الأيمن على النحو التالي‪ :‬الحد الأدنى ‪ 1‬والحد الأقصى متعدد‪.‬‬

‫‪ 7.4‬أنواع العلاقات‬

‫يشير السطر ال ذي يرب ط ج دولين في مخط ط الكي ان والعلاق ة ‪- entity relationship diagram‬أو ‪ERD‬‬
‫اختصا ًرا‪ -‬إلى نوع العلاقة بين الجدولين؛ فهي إما وثيقة أو معرَّفة ‪ identifying‬أو غير وثيقة ‪.non-identifying‬‬

‫‪73‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫العلاقة الوثيقة هي خط متصل بحيث يحتوي المفتاح الرئيسي ‪ PK‬على المفتاح الخارجي ‪ ،FK‬كما يش ار إلى‬
‫العلاقة الغير وثيقة بخط متقطع مع عدم وجود المفتاح الخارجي ‪ FK‬ضمن المفتاح الرئيسي ‪.PK‬‬

‫‪ 7.4.1‬العلاقات الاختيارية‬

‫يمكن أن يكون للمفتاح الخارجي ‪ FK‬قيم ًة فارغ ًة في العلاقة الاختياري ة أو لا يحت اج الج دول الأب إلى وج ود‬
‫جدول ابن مطابق‪.‬‬

‫نو ًعا مك َّونًا من صفر وثلاث ب روزات ‪-‬تش ير إلى متع دد‪ -‬وال ذي يُف َّس ر‬ ‫يوضح الرمز المب َّين في الشكل‬

‫على أنه علاقة صفر أو متعدد ‪.zero OR many‬‬

‫إذا نظرت إلى جدول الطلبات ‪ Order table‬على الجانب الأيمن من الشكل الآتي مثاًل ‪ ،‬فستلاحظ عدم حاجة‬
‫العميل ‪ customer‬إلى تقديم طلب ليكون عمياًل ‪ ،‬أي أن الجانب المتعدد اختياري‪ ،‬ويو ِّضح الشكل التالي المث ال‬

‫السابق عن كيفية استخدام رمز العلاقة الاختيارية صفر إلى متعدد ‪:zero to many‬‬

‫‪74‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫يمكن أي ًضا قراءة رمز العلاقة في الشكل السابق على النحو التالي‪:‬‬

‫• الجانب الأيسر‪ :‬يجب احتواء كيان الطلب ‪ order entity‬على كيان واحد مرتبط على أساس حد أدنى في‬
‫جدول العميل ‪ ،Customer table‬وكيان واحد مرتبط على أساس حد أقصى‪.‬‬

‫• الج انب الأيمن‪ :‬يمكن للعمي ل ع دم تق ديم طلب ات (أي ص فر طلب) على أس اس ح د أدنى‪ ،‬أو تق ديم‬
‫طلبات متعددة على أساس حد أقصى‪.‬‬

‫نو ًع ا آخ رًا من رم وز العلاق ة الاختياري ة بص فر وواح د‪ ،‬أي علاق ة ص فر أو‬ ‫يو ِّض ح الش كل‬

‫واحد ‪ ،zero OR one‬حيث جانب الواحد اختياري‪.‬‬
‫يو ِّضح الشكل التالي مثااًل عن كيفية استخدام رمز العلاقة الاختيارية صفر إلى واحد ‪:zero to one‬‬

‫‪75‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫‪ 7.4.2‬العلاقات الإلزامية ‪Mandatory relationships‬‬

‫يتطلب حدوث كيان واحد حدوث كيان مقابل في العلاقة الإلزامية‪ .‬يُظ ِهر رمز هذه العلاقة علاق ة واح د فق ط‬
‫‪ one and only one‬كما في الشكل ‪ ،‬أي أن الجانب واحد ‪ one side‬إلزامي‪.‬‬

‫يو ِّضح الشكل مثااًل عن كيفية استخدام رمز العلاقة الإلزامية واحد فقط ‪:one and only one‬‬

‫يو ِّضح الشكل رمز علاقة واحد إلى متع دد ‪ one to many‬حيث يك ون الج انب المتع دد ‪many side‬‬
‫إلزام ًيا‪ ،‬ويو ِّضح الشكل التالي مثااًل عن كيفية استخدام رمز العلاقة الإلزامية واحد إلى متعدد‪:‬‬
‫‪76‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫رأينا أن الجانب الداخلي من رمز العلاقة المو َّضح على الج انب الأيس ر من الرم ز في الش كل الآتي يمكن أن‬
‫يكون له تعددية العلاقة ‪ cardinality‬قيمتها ‪ 0‬وارتباط ‪ connectivity‬متعدد كما هو مو َّض ح على الج انب الأيمن‬

‫ولا يمكن أن يك ون لدي ه‬ ‫من الرمز في الشكل التالي‪ ،‬أو ارتباط قيمته واحد وه و غ ير مو َّض ح في الش كل‬

‫ارتباط قيمته ‪ ،0‬كما هو في الشكل ‪ ،‬إذ يمكن أن يكون الارتباط ‪ 1‬فقط‪.‬‬

‫تُظ ِهر رموز الارتباط الحدود القصوى‪ ،‬فإذا أظهر رمز الارتباط على الجانب الأيسر القيم ة ‪ ،0‬فلن يك ون هن اك‬
‫ارتباط بين الجداول‪.‬‬

‫فيما يلي طريقة قراءة رمز العلاقة مثل الرمز الموجود في الشكل الآتي‪:‬‬

‫• يجب العث ور على مع رِّف العمي ل ‪ CustID‬في ج دول الطلب ات ‪ Order table‬وفي ج دول العملاء‬
‫‪ Customer table‬أي ًضا بحد أدنى ‪ 0‬وبحد أقصى ‪ 1‬مرة‪.‬‬

‫• تعني القيمة ‪ 0‬أن معرِّف العميل ‪ CustID‬في جدول الطلبات ‪ Order table‬قد تكون قيمته فارغة ‪.null‬‬

‫• تشير القيمة ‪ 1‬الموجودة أقصى اليسار ‪-‬أي قبل القيمة ‪ 0‬مباشر ًة ال تي تمث ل الارتب اط‪ -‬إلى أن ه إذا ك ان‬
‫هناك معرِّف عميل ‪ CustID‬في جدول الطلبات ‪ ،Order table‬فيمكن وجود ه ذا المع رِّف في ج دول‬

‫العملاء ‪ Customer table‬مر ًة واحد ًة فقط‪.‬‬

‫• يمكنك افتراض شيئين عندما ترى الرمز ‪ 0‬لتعددية العلاقة ‪:cardinality‬‬

‫‪ .1‬يسمح المفتاح الخارجي ‪ FK‬في جدول الطلبات ‪ Order table‬بوجود القيم الفارغة‪.‬‬

‫‪ .2‬ليس المفتاح الخارجي ‪ FK‬جز ًءا من المفتاح الرئيسي ‪ PK‬لأن ه يجب ألا تحت وي المف اتيح الرئيس ية‬
‫على قيم فارغة ‪.null‬‬

‫‪77‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫‪ 7.5‬مصطلحات أساسية‬

‫• قواعد العمل ‪ :business rules‬نحصل عليها من المستخ ِدمين عند جمع المتطلبات‪ ،‬وتُستخ َدم‬
‫لتحديد عددية العلاقة ‪.cardinality‬‬

‫• عددية العلاقة ‪ :cardinality‬تُع ِبّر عن الحد الأدنى والحد الأقصى لعدد مرات حدوث الكيان المرتبط‬
‫بحدوث كيان ذي صلة‪.‬‬

‫• الارتباط ‪ :connectivity‬وهو يم ِّثل العلاقة بين جدولين‪ ،‬مثل‪ :‬علاقة واحد إلى واحد‪ ،‬أو علاقة واحد‬
‫إلى متعدد‪.‬‬

‫• القيود ‪ :constraints‬تُم ِّثل القواعد التي تجبر نظم إدارة قواعد البيانات ‪ DBMSs‬على التحقق من أن‬
‫البيانات توافق الدلالات ‪.semantics‬‬

‫• سلامة الكيان ‪ :entity integrity‬تتطلب وجود مفتاح رئيسي ‪ primary key‬لكل جدول‪ ،‬كما لا يمكن‬
‫أن يحتوي المفتاح الرئيسي ولا أي جزء منه على قيم فارغة ‪.null‬‬

‫• العلاقة ال ُمع َّرفة ‪ :identifying relationship‬حيث يحتوي المفتاح الرئيسي على المفتاح الخارجي‬
‫‪ ،foreign key‬ويشار إليها في مخطط ‪ ERD‬بخ ٍط متصل‪.‬‬

‫• قيود السلامة ‪ :integrity constraints‬هي التعليمات المنطقية التي تحدد قيم البيانات المسموح‬
‫بها أو غير المسموح بها‪ ،‬كما تحدد التنسيق المناسب للسمة ‪.attribute‬‬

‫• العلاقة الإلزامية ‪ :mandatory relationship‬يتطلب حدوث كيان واحد حدوث كيان مقابل‪.‬‬
‫• العلاقة الغير ُمع َّرفة ‪ :non-identifying relationship‬لا تحتوي على المفتاح الخارجي ضمن المفتاح‬

‫الرئيسي‪ ،‬ويشار إليها في مخطط ‪ ERD‬بخط من َّقط‪.‬‬
‫• العلاقة الاختيارية ‪ :optional relationship‬حيث يمكن أن يكون للمفتاح الخارجي ‪ FK‬قيم ًة فارغ ًة‪،‬‬

‫أو عندما لا يحتاج الجدول الأب إلى وجود جدول ابن مطابق‪.‬‬
‫• السجل اليتيم ‪ :orphan record‬هو السجل الذي لم يُع َثر على قيمة مفتاحه الخارجي في الكيان‬

‫المقابل أي في الكيان الذي يوجد به المفتاح الرئيسي‪.‬‬

‫‪78‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫• السلامة المرجعية ‪ :referential integrity‬تتطلب أن يكون للمفتاح الخارجي مفتاحًا رئيس ًيا مطاب ًقا‪،‬‬
‫وإاّل فيجب أن يكون للمفتاح الخارجي قيم ًة فارغ ًة‪.‬‬

‫• نظام إدارة قواعد البيانات العلائقية ‪ relational database management system‬أو ‪:RDBMS‬‬
‫وهو نظام قاعدة بيانات شائع‪ ،‬حيث يعتمد على النموذج العلائقي الذي ق ّدمه إدجار‬
‫كود ‪ E.F. Codd‬من مختبر أبحاث سان خوسيه ‪ San Jose‬التابع لشركة ‪.IBM‬‬

‫• نوع العلاقة ‪ :relationship type‬هو نوع العلاقة بين جدولين في مخطط ‪ ،ERD‬أي إما علاقة وثيقة أو‬
‫معرَّفة ‪ ،identifying‬أو غير وثيقة ‪ ،non-identifying‬ويُشار إلى هذه العلاقة بخط مرسوم بين جدولين‪.‬‬

‫‪ 7.6‬تمارين‬

‫اقرأ الوصف التالي ثم أجب عن الأسئلة‪:‬‬

‫ُص ِّممت قاعدة بيان ات ن ادي الس باحة في الش كل الآتي لتحت وي على معلوم ات ح ول الطلاب ‪students‬‬
‫المس جَلين ‪ enrolled‬في ص فوف الس باحة‪ ،‬حيث خُزِّنت المعلوم ات التالي ة‪ :‬الطلاب ‪ ،students‬والتس جيل‬
‫‪ ،enrollment‬وص فوف الس باحة ‪ ،swim classes‬والمس ابح ‪ pools‬ال تي تق ام فيه ا الص فوف‪ ،‬وم دربو‬

‫‪ instructors‬صفوف السباحة‪ ،‬والمستويات ‪ levels‬المختلفة من صفوف السباحة‪.‬‬

‫استخدم الشكل التالي للإجابة على الأسئلة‪:‬‬

‫حُ ِّددت المفاتيح الرئيسية ‪ ،primary keys‬و ُعرِّفت أنواع البيانات التالية في خادم ‪.SQL Server‬‬
‫‪79‬‬

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

**tblLevels**
Level – Identity PK
ClassName – text 20 – nulls are not allowed

**tblPool**
Pool – Identity PK
PoolName – text 20 – nulls are not allowed
Location – text 30

**tblStaff**
StaffID – Identity PK
FirstName – text 20
MiddleInitial – text 3
LastName – text 30
Suffix – text 3
Salaried – Bit
PayAmount – money

**tblClasses**
LessonIndex – Identity PK
Level – Integer FK
SectionID – Integer
Semester – TinyInt
Days – text 20
Time – datetime (formatted for time)
Pool – Integer FK
Instructor – Integer FK
Limit – TinyInt
Enrolled – TinyInt
Price – money

**tblEnrollment**
LessonIndex – Integer FK
SID – Integer FK (LessonIndex and SID) Primary Key
Status – text 30
Charged – bit

80

‫تصميم قواعد البيانات‬ ‫قواعد السلامة وقيودها لضمان سلامة البيانات‬

‫‪AmountPaid – money‬‬
‫‪DateEnrolled – datetime‬‬
‫**‪**tblStudents‬‬
‫‪SID – Identity PK‬‬
‫‪FirstName – text 20‬‬
‫‪MiddleInitial – text 3‬‬
‫‪LastName – text 30‬‬
‫‪Suffix – text 3‬‬
‫‪Birthday – datetime‬‬
‫‪LocalStreet – text 30‬‬
‫‪LocalCity – text 20‬‬
‫‪LocalPostalCode – text 6‬‬
‫‪LocalPhone – text 10‬‬

‫ط ّبق هذا المخطط في خادم ‪ ،SQL Server‬أو باس تخدام نظ ام ‪ access‬وعن دها س تحتاج إلى اختي ار أن واع‬
‫بيانات قابلة للموازنة‪.‬‬

‫‪ .1‬اش رح قواع د العلاق ة ‪ relationship rules‬لك ل علاق ة مث ل العلاق ة بين الج دولين ‪tblEnrollment‬‬
‫و‪ tblStudents‬التي تم ِّثل إمكانية تسجيل الطالب في صفوف سباحة متعددة‪.‬‬

‫‪ .2‬ح ّدد عددية ‪ cardinality‬كل علاقة بافتراض القواعد التالية‪:‬‬

‫◦ قد يكون أو لا يكون للمسبح ‪ pool‬ص ًفا ‪ class‬للسباحة‪.‬‬

‫◦ يجب ارتباط جدول المستويات ‪ levels table‬دائ ًما بصف سباحة واحد على الأقل‪.‬‬

‫◦ قد لا يدرِّس جدول فريق التدريب ‪ staff table‬أ َّي صف سباحة‪.‬‬

‫◦ يجب تسجيل جميع الطلاب في صف سباحة واحد على الأقل‪.‬‬

‫◦ يجب احتواء صف السباحة على طلاب مسجلين فيه‪.‬‬

‫◦ يجب امتلاك صف السباحة على مسبح صالح‪.‬‬

‫◦ قد لا يُع َّين مدرب لصف السباحة‪.‬‬

‫◦ يجب ارتباط صف السباحة دائ ًما بمستوى موجود‪.‬‬

‫‪ .3‬ح ّدد الجداول الضعيفة‪ ،‬والجداول القوية التي شرحناها في مقا ٍل سابق‪.‬‬
‫‪ .4‬ح ّدد الجداول ال ُمعرَّفة ‪ ،identifying‬والجداول غير ال ُمعرَّفة ‪.non-identifying‬‬

‫‪81‬‬

‫‪ .8‬نمذجة الكيان العلاقي ‪ ER‬عند‬

‫تصميم قواعد البيانات‬

‫تتض من إح دى النظري ات المهم ة ال تي طُ ِّورت لنم وذج الكي ان العلاقي )‪ entity relational (ER‬فك رة‬
‫الاعتمادي ة الوظيفي ة ‪( functional dependency‬اختص ا ًرا ‪ ،)FD‬واله دف من دراس تها ه و تحس ين فهم ك‬

‫للعلاقات بين البيانات‪ ،‬واكتساب المنهجية الكافية للمساعدة في التصميم العملي لقاعدة البيانات‪.‬‬
‫تُستخلَص الاعتماديات الوظيفية ‪ FD‬من دلالات ‪ semantics‬نطاق التطبيق‪ ،‬أي مث ل القي ود ‪constraints‬‬
‫التي شرحناها في الفصل السابق‪ ،‬وت ِصف كيفي ة ارتب اط الس مات المنفص لة ‪ individual attributes‬ببعض ها‬
‫البعض‪ ،‬كما تُ َع ّد الاعتماديات الوظيفي ة ‪ FD‬نو ًع ا من القي ود بين الس مات داخ ل علاق ة‪ ،‬وتس اهم في تص ميم‬

‫مخطط علاقي جيد‪ ،‬حيث سنلقي في هذا الفصل نظر ًة على‪:‬‬
‫• نظرية الاعتمادية الوظيفية الأساسية وتعريفها‪.‬‬

‫• منهجية تحسين تصميمات المخططات‪ ،‬وتسمى أي ًضا التوحيد ‪.normalization‬‬

‫‪ 8.1‬التصميم العلاقي ‪ Relational Design‬والتكرار ‪Redundancy‬‬

‫يجب احتواء التصميم الجيد لقاعدة البيانات العلاقية على جميع السمات والارتباط ات الض رورية‪ ،‬إذ يق وم‬
‫التصميم بذلك بأقل قدرٍ ممكن من المعلومات المخزَّنة مع عدم وجود بيانات مكرَّرة ‪.redundant‬‬

‫يُ َع ّد التكرار أم ًرا غير مرغوب فيه في تصميم قاعدة البيانات‪ ،‬وذلك لأنه يسبب المش كلات في الحف اظ على‬
‫التناسق بعد التحديثات‪ ،‬لكن يمكن أن ي ؤدي التك رار إلى تحس ينات في الأداء في بعض الأحي ان مث ل إمكاني ة‬
‫استخدام التكرار بداًل من عملية الض م ‪ join‬لرب ط البيان ات‪ ،‬حيث تُس تخ َدم عملي ة الض م ‪ join‬عن د الحاج ة إلى‬

‫الحصول على معلومات تستند إلى جدولين مرتبطين‪.‬‬

‫تصميم قواعد البيانات‬ ‫نمذجة الكيان العلاقي ‪ ER‬عند تصميم قواعد البيانات‬

‫ض ع في بال ك الج دول الآتي ال ذي يو ِّض ح مث ااًل عن التك رار ال ُمس تخ َدم في الحس ابات‬
‫المصرفية ‪ ،Bank Accounts‬وفروع المصرف ‪ ،Branches‬حيث يَظه ر العمي ل رقم ‪ 1313131‬م رتين‪ ،‬أي م ر ًة‬
‫للحساب ذو الرقم ‪ ،A-101‬ومر ًة أخرى للحساب رقم ‪A-102‬؛ إذ لا يك ون رقم العمي ل زائ ًدا في ه ذه الحال ة على‬
‫الرغم من وجود حالات حذ ٍف ش اذة ‪ deletion anomalies‬في الج دول‪ ،‬وس يحل ه ذه المش كلة وج ود ج دول‬

‫منفصل للعملاء‪.‬‬

‫إذا تغير عنوان الفرع ‪ ،branch address‬فيجب تحديثه في أماكن متعددة‪ ،‬وإذا تُرِك رقم العميل في الجدول‬
‫كما هو‪ ،‬فلن تحتاج إلى جدول للفرع ‪ ،branch‬ولن تكون هناك حاجة إلى عملية ضم‪ ،‬وبالتالي‪ ،‬سيتح ّسن الأداء‪.‬‬

‫‪accountNo‬‬ ‫‪blance‬‬ ‫‪customer‬‬ ‫‪branch‬‬ ‫‪address‬‬ ‫‪assets‬‬
‫‪A-101‬‬ ‫‪500‬‬ ‫‪1313131‬‬ ‫‪Downtown‬‬ ‫‪Brooklyn‬‬ ‫‪9000000‬‬
‫‪A-102‬‬ ‫‪400‬‬ ‫‪1313131‬‬ ‫‪Perryridge‬‬ ‫‪Horseneck‬‬ ‫‪1700000‬‬
‫‪A-113‬‬ ‫‪600‬‬ ‫‪9876543‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬
‫‪A-201‬‬ ‫‪900‬‬ ‫‪9676543‬‬ ‫‪brighton‬‬ ‫‪Brooklyn‬‬ ‫‪7100000‬‬
‫‪A-215‬‬ ‫‪700‬‬ ‫‪1111111‬‬ ‫‪Manus‬‬ ‫‪Horseneck‬‬ ‫‪400000‬‬
‫‪A-222‬‬ ‫‪700‬‬ ‫‪1111111‬‬ ‫‪Redwood‬‬ ‫‪Palo Alto‬‬ ‫‪2100000‬‬
‫‪A-305‬‬ ‫‪350‬‬ ‫‪1234567‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬

‫‪ 8.2‬حالة الإدخال الشاذة ‪Insertion Anomaly‬‬

‫تحدث ه ذه الحال ة عن د إدخ ال معلوم ات متض اربة في ج دول‪ ،‬حيث نحت اج إلى التحق ق من أن بيان ات‬
‫الفرع ‪ branch‬متوافقة مع الصفوف الموجودة عن دما ن دخل س جاًل جدي ًدا مث ل رقم الحس اب ‪ ،A-306‬كم ا في‬

‫الجدول التالي‪:‬‬

‫‪accountNo‬‬ ‫‪blance‬‬ ‫‪customer‬‬ ‫‪branch‬‬ ‫‪address‬‬ ‫‪assets‬‬
‫‪1313131‬‬ ‫‪Downtown‬‬ ‫‪Brooklyn‬‬ ‫‪9000000‬‬
‫‪A-101‬‬ ‫‪500‬‬ ‫‪1313131‬‬ ‫‪Perryridge‬‬ ‫‪Horseneck‬‬ ‫‪1700000‬‬
‫‪9876543‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬
‫‪A-102‬‬ ‫‪400‬‬ ‫‪9676543‬‬ ‫‪brighton‬‬ ‫‪Brooklyn‬‬ ‫‪7100000‬‬
‫‪1111111‬‬ ‫‪Manus‬‬ ‫‪Horseneck‬‬ ‫‪400000‬‬
‫‪A-113‬‬ ‫‪600‬‬ ‫‪1111111‬‬ ‫‪Redwood‬‬ ‫‪Palo Alto‬‬ ‫‪2100000‬‬
‫‪1234567‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬
‫‪A-201‬‬ ‫‪900‬‬ ‫‪1111111‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000800‬‬

‫‪A-215‬‬ ‫‪700‬‬

‫‪A-222‬‬ ‫‪700‬‬

‫‪A-305‬‬ ‫‪350‬‬

‫‪A-306‬‬ ‫‪800‬‬

‫‪83‬‬

‫تصميم قواعد البيانات‬ ‫نمذجة الكيان العلاقي ‪ ER‬عند تصميم قواعد البيانات‬

‫‪ 8.3‬حالة التحديث الشاذة ‪Update Anomaly‬‬

‫إذا غ ّير أحد فروع المصرف عنوانه مثل الفرع راون د هي ل ‪ Round Hill‬في الج دول الآتي‪ ،‬فنحن بحاج ة إلى‬
‫تحديث جميع الصفوف التي تشير إلى هذا الفرع‪ ،‬حيث يس ّمى تغيير المعلومات الموجودة بصورة غ ير ص حيحة‬

‫بحالة تحديث شاذة‪.‬‬

‫‪accountNo‬‬ ‫‪blance‬‬ ‫‪customer‬‬ ‫‪branch‬‬ ‫‪address‬‬ ‫‪assets‬‬
‫‪A-101‬‬ ‫‪500‬‬ ‫‪1313131‬‬ ‫‪Downtown‬‬ ‫‪Brooklyn‬‬ ‫‪9000000‬‬
‫‪A-102‬‬ ‫‪400‬‬ ‫‪1313131‬‬ ‫‪Perryridge‬‬ ‫‪Horseneck‬‬ ‫‪1700000‬‬
‫‪A-113‬‬ ‫‪600‬‬ ‫‪9876543‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬
‫‪A-201‬‬ ‫‪900‬‬ ‫‪9676543‬‬ ‫‪brighton‬‬ ‫‪Brooklyn‬‬ ‫‪7100000‬‬
‫‪A-215‬‬ ‫‪700‬‬ ‫‪1111111‬‬ ‫‪Manus‬‬ ‫‪Horseneck‬‬ ‫‪400000‬‬
‫‪A-222‬‬ ‫‪700‬‬ ‫‪1111111‬‬ ‫‪Redwood‬‬ ‫‪Palo Alto‬‬ ‫‪2100000‬‬
‫‪A-305‬‬ ‫‪350‬‬ ‫‪1234567‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬

‫‪ 8.4‬حالة الحذف الشاذة ‪Deletion Anomaly‬‬

‫تحدث هذه الحالة عند حذف سجل قد يحتوي على سمات لا ينبغي حذفها‪ ،‬إذا أزلنا معلومات حول الحساب‬
‫الأخير في أحد الفروع مثل الحساب رقم ‪ A-101‬في الفرع داون تاون ‪ Downtown‬في الجدول التالي على سبيل‬

‫المثال‪ ،‬فستختفي جميع معلومات ذلك الفرع‪.‬‬

‫‪accountNo‬‬ ‫‪blance‬‬ ‫‪customer‬‬ ‫‪branch‬‬ ‫‪address‬‬ ‫‪assets‬‬
‫‪A-101‬‬ ‫‪500‬‬ ‫‪1313131‬‬ ‫‪Downtown‬‬ ‫‪Brooklyn‬‬ ‫‪9000000‬‬
‫‪A-102‬‬ ‫‪400‬‬ ‫‪1313131‬‬ ‫‪Perryridge‬‬ ‫‪Horseneck‬‬ ‫‪1700000‬‬
‫‪A-113‬‬ ‫‪600‬‬ ‫‪9876543‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬
‫‪A-201‬‬ ‫‪900‬‬ ‫‪9676543‬‬ ‫‪brighton‬‬ ‫‪Brooklyn‬‬ ‫‪7100000‬‬
‫‪A-215‬‬ ‫‪700‬‬ ‫‪1111111‬‬ ‫‪Manus‬‬ ‫‪Horseneck‬‬ ‫‪400000‬‬
‫‪A-222‬‬ ‫‪700‬‬ ‫‪1111111‬‬ ‫‪Redwood‬‬ ‫‪Palo Alto‬‬ ‫‪2100000‬‬
‫‪A-305‬‬ ‫‪350‬‬ ‫‪1234567‬‬ ‫‪Round Hill‬‬ ‫‪Horseneck‬‬ ‫‪8000000‬‬

‫مشكلة حذف الصف ‪ A-101‬هي عدم معرفتنا مك ان الف رع ‪ ،Downtown‬وأنن ا س نفقد جمي ع المعلوم ات‬
‫المتعلقة بالعميل ‪.1313131‬‬

‫نحتاج إلى تفكيك الجدول الأصلي إلى جداول أصغر متعددة بحيث يكون لكل جدول ح ًدا أدنى من الت داخل‬
‫مع الجداول الأخرى‪ ،‬وذلك لتجنب هذه الأنواع من مشاكل التحديث أو الحذف‪.‬‬

‫‪84‬‬

‫تصميم قواعد البيانات‬ ‫نمذجة الكيان العلاقي ‪ ER‬عند تصميم قواعد البيانات‬

‫يجب احتواء كل جدول حساب مصرفي على معلومات حول كيان ‪ entity‬واحد فقط‪ ،‬مث ل‪ :‬الف رع ‪،Branch‬‬
‫أو العميل ‪ ،Customer‬كما هو موضح في الشكل التالي‪:‬‬

‫سيضمن اتباع هذه العملية أن إضافة معلومات الفرع أو تحديثها س يؤثر على س جل واح د فق ط‪ ،‬ل ذلك لن‬
‫تع َّدل معلومات الفرع عن طريق الخطأ‪ ،‬ولن تُسجَّل بصورة غ ير ص حيحة‪ ،‬وذل ك عن د إض افة معلوم ات العميل‬

‫أو حذفها‪.‬‬

‫‪ 8.4.1‬مثال تطبيقي‪ :‬جدول مشروع‪-‬موظف والحالات الشاذة‬

‫يو ِّضح الجدول الآتي مثااًل لجدول مشروع‪-‬موظف ‪ ،employee project table‬كما يمكننا الافتراض من هذا‬
‫الجدول أن‪:‬‬

‫‪ .1‬معرِّف الموظف ‪ ،EmpID‬ومعرِّف المشروع ‪ ProjectID‬هما المفتاح الرئيسي المر َّكب ‪.composite PK‬‬
‫‪ .2‬يحدد معرِّف المشروع الميزانية ‪ ،Budget‬أي أ ّن للمشروع ‪ P1‬ميزاني ًة لفترة ‪ 32‬ساعة‪.‬‬

‫‪EmpID‬‬ ‫‪Budget‬‬ ‫‪ProjectID‬‬ ‫‪Hours‬‬
‫‪S75‬‬ ‫‪32‬‬ ‫‪P1‬‬ ‫‪7‬‬
‫‪S75‬‬ ‫‪40‬‬ ‫‪P2‬‬ ‫‪3‬‬
‫‪S79‬‬ ‫‪32‬‬ ‫‪P1‬‬ ‫‪4‬‬
‫‪S79‬‬ ‫‪27‬‬ ‫‪P3‬‬ ‫‪1‬‬
‫‪S80‬‬ ‫‪40‬‬ ‫‪P2‬‬ ‫‪5‬‬
‫‪17‬‬ ‫‪P4‬‬

‫فيم ا يلي بعض الح الات الش اذة ‪ anomalies‬المحتمل ة ال تي ق د تح دث م ع ه ذا الج دول خلال‬
‫الخطوات التالية‪:‬‬

‫‪ .1‬الإجراء‪ :‬إضافة الصف ‪ Add row‬الذي هو {‪.}S85, 35, P1, 9‬‬

‫‪ .2‬المشكلة‪ :‬هناك صفان ‪ tuples‬بميزانيات متضاربة‪.‬‬

‫‪ .3‬الإجراء‪ :‬حذف الصف ‪ Delete tuple‬الذي هو {‪.}S79, 27, P3, 1‬‬

‫‪ .4‬المشكلة‪ :‬الخطوة رقم ‪ 3‬تحذف ميزانية المشروع ‪.P3‬‬

‫‪85‬‬

‫تصميم قواعد البيانات‬ ‫نمذجة الكيان العلاقي ‪ ER‬عند تصميم قواعد البيانات‬

‫‪ .5‬الإجراء‪ :‬تحديث الصف ‪ Update tuple‬من {‪ }S75, 32, P1, 7‬إلى {‪.}S75, 35, P1, 7‬‬
‫‪ .6‬المشكلة‪ :‬تُن ِشئ الخطوة رقم ‪ 5‬ص َّفين بقيم مختلفة لميزانية المشروع ‪.P1‬‬

‫‪ .7‬الحل‪ :‬إنشاء جدول منفصل ‪ separate table‬لكل من المشاريع ‪ Projects‬والموظفين ‪ ،Employees‬أي‬
‫كما هو مو َّضح في الشكل التالي‪:‬‬

‫‪ 8.5‬كيفية تجنب الحالات الشاذة‬

‫أفضل طريقة لإنشاء جداول بدون حالات شاذة هي التأكد من توحيد الجداول‪ ،‬ويتحق ق ذل ك من خلال فهم‬
‫الاعتماديات الوظيفية‪ ،‬حيث تضمن الاعتمادية الوظيفية ‪ FD‬في جدول انتم اء جمي ع الس مات ‪ attributes‬إلى‬

‫هذا الجدول‪ ،‬أي ستزيل التكرار والحالات الشاذة‪.‬‬

‫‪ 8.5.1‬مثال تطبيقي‪ :‬جدولا المشاريع والموظفين المنفصلان‬

‫جدول المشروع ‪Project‬‬

‫‪ProjectID‬‬ ‫‪Budeget‬‬
‫‪P1‬‬ ‫‪32‬‬
‫‪P2‬‬ ‫‪40‬‬
‫‪P3‬‬ ‫‪27‬‬
‫‪P4‬‬ ‫‪17‬‬

‫جدول الموظف ‪Employee‬‬

‫‪Emp ID‬‬ ‫‪Project ID‬‬ ‫‪Hours‬‬
‫‪S75‬‬ ‫‪P1‬‬ ‫‪7‬‬
‫‪S75‬‬ ‫‪P2‬‬ ‫‪3‬‬
‫‪S79‬‬ ‫‪P1‬‬ ‫‪4‬‬
‫‪S79‬‬ ‫‪P3‬‬ ‫‪1‬‬
‫‪S80‬‬ ‫‪P2‬‬ ‫‪5‬‬

‫يكون من خلال الاحتفاظ بالبيانات منفصلة باستخدام جدول مشاريع وجدول موظفين ما يلي‪:‬‬

‫• لن تُن َشأ حالات شاذة إذا تغيرت الميزانية‪.‬‬

‫‪86‬‬

‫تصميم قواعد البيانات‬ ‫نمذجة الكيان العلاقي ‪ ER‬عند تصميم قواعد البيانات‬

‫• ليست هناك حاجة إلى قيم وهمية للمشاريع التي لم يُع َّين لها موظفون‪.‬‬
‫• إذا حُ ِذفت مساهمة موظف ما‪ ،‬فلن تُف َقد بيانات مهمة‪.‬‬
‫• لن تُن َشأ حالات شاذة إذا ُأضيفت مساهمة موظف‪.‬‬

‫‪ 8.6‬مصطلحات أساسية‬

‫• حالة الحذف الشاذة ‪ :deletion anomaly‬وتحدث هذه الحالة عند حذف سجل قد يحتوي على سمات‬
‫لا ينبغي حذفها‪.‬‬

‫• الاعتمادية الوظيفية ‪ functional dependency‬أو ‪ :FD‬ت ِصف كيفية ارتباط السمات المنفصلة‬
‫‪ individual attributes‬ببعضها البعض‪.‬‬

‫• حالة الإدخال الشاذة ‪ :insertion anomaly‬تحدث عند إدخال معلومات متضاربة في جدول‪.‬‬
‫• عملية الضم ‪ :join‬تُستخدم هذه العملية عندما تحتاج إلى الحصول على معلومات بنا ًء على جدولين‬

‫متعلقين ببعضهما‪.‬‬

‫• حالة التحديث الشاذة ‪ :update anomaly‬تغيير المعلومات الموجودة بصورة غير صحيحة‪.‬‬

‫‪ 8.7‬تمارين‬

‫أواًل ‪ :‬طبِّق التوحيد ‪ normalization‬على الجدول التالي‪:‬‬

‫‪Attribute Name‬‬ ‫‪Sample Value‬‬ ‫‪Sample Value‬‬ ‫‪Sample Value‬‬
‫‪2‬‬ ‫‪3‬‬
‫‪StudentID‬‬ ‫‪1‬‬ ‫‪Sandy Law‬‬ ‫‪Sue Rogers‬‬
‫‪2‬‬ ‫‪3‬‬
‫‪StudentName John Smith‬‬ ‫‪Programming Level 1‬‬ ‫‪Business‬‬
‫‪61%‬‬ ‫‪81%‬‬
‫‪CourselD‬‬ ‫‪2‬‬ ‫‪Jan 5th, 2014‬‬ ‫‪Jan 7th, 2014‬‬

‫‪CourseName Programming Level 1‬‬

‫‪Grade‬‬ ‫‪75%‬‬

‫‪CourseDate‬‬ ‫‪Jan 5th, 2014‬‬

‫‪87‬‬

‫تصميم قواعد البيانات‬ ‫نمذجة الكيان العلاقي ‪ ER‬عند تصميم قواعد البيانات‬

‫ثان ًيا‪ :‬أن ِشئ مخطط ‪ ERD‬منطقي لخدمة تأجير الأفلام عبر الإنترنت‪ ،‬حيث لا توجد علاقات من النوع متع دد‬
‫إلى متع دد ‪ ،many to many‬واس تخدم الوص ف الت الي للعملي ات ال تي يجب أن تس تند عليها‬

‫قواعد عملك‪:‬‬

‫تُص ّنِف خدمة تأجير الأفلام عبر الإنترنت عناوين الأفلام وف ًقا لنوعها إلى‪ :‬الأفلام الكوميدية ‪ ،comedy‬وأفلام الغرب‬
‫الأمريكي ‪ ،western‬والأفلام الكلاسيكية ‪ ،classical‬وأفلام الخيال العلمي ‪ ،science fiction‬وأفلام الرسوم‬

‫المتحركة ‪ ،cartoon‬وأفلام الحركة ‪ ،action‬والأفلام الموسيقية ‪ ،musical‬والأفلام المصدرة حدي ًثا ‪.new release‬‬

‫يحتوي كل نوع على العديد من العن اوين المحتمل ة‪ ،‬وتت وفر نس خ ‪ copies‬متع ددة لمعظم العن اوين داخ ل‬
‫النوع‪ ،‬فمثاًل ‪ ،‬لاحظ الملخَّص التالي‪:‬‬
‫‪TYPE TITLE .1‬‬

‫‪Musical My Fair Lady (Copy 1) .2‬‬
‫‪My Fair Lady (Copy 2) .3‬‬
‫‪Oklahoma (Copy 1) .4‬‬
‫‪Oklahoma (Copy 2) .5‬‬
‫‪Oklahoma (Copy 3) .6‬‬
‫‪... .7‬إلخ‪.‬‬

‫ثال ًثا‪ :‬ما هي الحالات الشاذة الثلاثة للبيانات التي من المحتمل تَشكّلها نتيج ًة لتكرار البيانات؟ وكي ف يمكن‬
‫القضاء على مثل هذه الحالات الشاذة؟‬

‫سنتطرق في فصل لاحق لمثال عملي حول تصميم قاعدة بيانات كاملة من الصفر كتدريب عملي‪.‬‬

‫‪88‬‬

‫‪ .9‬الاعتماديات الوظيفية ‪Functional‬‬
‫‪Dependencies‬‬

‫الاعتمادية الوظيفية ‪- functional dependency‬أو ‪ FD‬اختصا ًرا‪ -‬هي علاقة بين سم َتين ‪ ،attributes‬حيث‬
‫تكون عاد ًة بين المفتاح الرئيسي ‪ PK‬والسمات الأخرى التي ليست مفاتيحًا ‪ non-key attributes‬داخل الجدول‪،‬‬
‫إذ تعتمد السمة ‪ Y‬وظيف ًيا على السمة ‪- X‬والتي تُ َعد مفتا ًحا رئيس ًيا ‪ -PK‬في علاق ة ‪ R‬إذا ح ّددت قيم ُة الس مة ‪X‬‬

‫قيم َة السمة ‪ Y‬بصور ٍة فريدة لكل نسخ ٍة صالحة من السمة ‪ ،X‬ويشار إلى هذه العلاقة من خلال التمثيل التالي‪:‬‬
‫‪X ——> Y‬‬

‫يسمى الجانب الأيسر من مخطط الاعتمادية الوظيفية ‪ FD‬السابق بالمح ِّدد ‪ ،determinant‬ويسمى الجانب‬
‫الأيمن بالاعتمادي ‪ ،dependent‬وفيما يلي بعض الأمثلة على ذلك‪.‬‬

‫تح ِّدد الس مة ‪ SIN‬الاس م ‪ ،Name‬والعن وان ‪ ،Address‬وت اريخ الميلاد ‪ Birthdate‬في المث ال الأول أدن اه‪،‬‬
‫حيث يمكننا تحديد أي من السمات الأخرى داخل الجدول باستخدام السمة ‪.SIN‬‬

‫‪SIN ——> Name, Address, Birthdate‬‬
‫تح ِّدد السمتان ‪ ،SIN‬و‪ Course‬ت اريخ الانته اء ‪ DateCompleted‬في المث ال الث اني‪ ،‬حيث يجب أن يعم ل‬

‫هذا أي ًضا مع مفتاح رئيسي مر ّكب ‪.composite PK‬‬
‫‪SIN, Course ——> DateCompleted‬‬

‫يشير المثال الثالث إلى أن السمة ‪ ISBN‬تح ّدد العنوان ‪.Title‬‬
‫‪ISBN ——> Title‬‬

‫تصميم قواعد البيانات‬ ‫الاعتماديات الوظيفية ‪Functional Dependencies‬‬

‫‪ 9.1‬قواعد الاعتماديات الوظيفية‬

‫انظر إلى جدول البيانات (‪ r(R‬لمخطط العلاقة (‪ R(ABCDE‬التالي‪:‬‬

‫‪ABCDE‬‬
‫‪a1 b1 c1 d1 e1‬‬
‫‪a2 b1 c2 d2 e1‬‬
‫‪a3 b2 c1 d1 e1‬‬
‫‪a4 b2 c2 d2 e1‬‬
‫‪a5 b3 c3 d1 e1‬‬
‫قد تسأل نفسك عند النظر إلى هذا الجدول‪ :‬ما نوع الاعتمادي ات ال تي يمكنن ا ملاحظته ا بين الس مات في‬

‫الجدول ‪R‬؟‬

‫بما أ ّن قيم السمة ‪ A‬فريدة ‪ a1, a2, a3, etc‬فيمكن القول اعتما ًدا على تعريف الاعتمادية الوظيفية ‪ FD‬أ ّن‪:‬‬

‫‪A —> B,‬‬
‫‪A —> C,‬‬
‫‪A —> D,‬‬
‫‪A —> E‬‬

‫• ويترتب على ذلك أي ًضا أن ‪ ،A → BC‬أو أي مجموعة فرعية أخرى من المجموعة ‪.ABCDE‬‬

‫• يمكن تلخيص ذلك على أساس ‪.A → BCDE‬‬

‫• تُ َع ّد السمة ‪ A‬مفتا ًحا رئيس ًيا‪.‬‬
‫بما أن قيم السمة ‪ E‬هي نفسها دائ ًما أي كلها لها القيمة ‪ ،e1‬فهذا يعني أ ّن‪:‬‬

‫‪A —> E,‬‬
‫‪B —> E,‬‬
‫‪C —> E,‬‬
‫‪D —> E‬‬

‫ولكن لا يمكننا تلخيص ما سبق باستخدام ‪ ،ABCD → E‬وذلك لأ ّن‪:‬‬

‫‪A —> E,‬‬
‫‪B —> E,‬‬
‫‪AB —> E‬‬

‫‪90‬‬

‫تصميم قواعد البيانات‬ ‫الاعتماديات الوظيفية ‪Functional Dependencies‬‬

‫‪ 9.1.1‬ملاحظات أخرى‬

‫‪ .1‬تركيبات ‪ BC‬فريدة‪ ،‬لذلك ‪.BC → ADE‬‬
‫‪ .2‬تركيبات ‪ BD‬فريدة‪ ،‬لذلك ‪.BD → ACE‬‬
‫‪ .3‬إذا كانت قيم السمة ‪ C‬متطابقة‪ ،‬فإن قيم السمة ‪ D‬متطابقة كذلك‪.‬‬

‫‪ .4‬لذلك ‪.C → D‬‬
‫‪ .5‬ولكن لا تح ِّدد قيم السمة ‪ D‬قيم السمة ‪.C‬‬
‫‪ .6‬لذلك لا تح ّدد السمة ‪ C‬السمة ‪ ،D‬ولا تح ِّدد السمة ‪ D‬السمة ‪.C‬‬
‫يمكن مساعدة النظر إلى البيانات الفعلي ة في توض يح الس مات ال تي هي س مات اعتمادي ة ‪،dependent‬‬
‫والسمات التي هي سمات مح ِّددة ‪.determinant‬‬

‫‪ 9.2‬قواعد الاستدلال ‪Inference Rules‬‬

‫تُ َع ّد بديهيات أرمسترونغ ‪ Armstrong's axioms‬مجموع ًة من قواعد الاستدلال المستخ َدمة لاستنتاج جميع‬
‫الاعتمادي ات الوظيفي ة في قاع دة بيان ات علائقي ة‪ ،‬حيث ط َّور ويلي ام أرمس ترونغ ‪William W. Armstrong‬‬

‫هذه البديهيات‪.‬‬
‫لنفترض أ ّن (‪ R(U‬هو مخطط علاقة لمجموع ة س مات ‪ ،U‬حيث سنس تخدم الأح رف ‪ ،X‬و‪ ،Y‬و‪ Z‬لتمثي ل أي‬

‫مجموعة فرعية‪ ،‬أو اتحاد ‪ union‬مجموعتين من السمات اختصا ًرا‪ ،‬بداًل من استخدام ‪.X U Y‬‬

‫‪ 9.2.1‬بديهية الانعكاس ‪Axiom of reflexivity‬‬

‫تنص هذه البديهية على أنه إذا كانت ‪ Y‬مجموعة فرعية ‪ subset‬من ‪ ،X‬فإ ّن ‪ X‬تح ِّدد ‪ ،Y‬كما في المعادلة‪:‬‬
‫‪if Y ⊆ X then X →Y‬‬

‫اف ترض الاعتمادي ة الوظيفي ة ‪ PartNo —> NT123‬على س بيل المث ال‪ ،‬حيث ت تر ّكب (‪ X(PartNo‬من‬
‫معلومات متعددة‪ ،‬وهي‪ ،Y(NT( :‬و (‪.partID(123‬‬

‫‪ 9.2.2‬بديهية الزيادة ‪Axiom of augmentation‬‬

‫تنص بديهية الزيادة ‪-‬والمعروفة باسم الاعتمادية الجزئية ‪ partial dependency‬أي ًضا‪ -‬على أن ه إذا ك انت ‪X‬‬
‫تح ِّدد ‪ ،Y‬فإ ّن ‪ XZ‬تحدد ‪ YZ‬مهما كانت ‪:Z‬‬

‫‪if X →Y then XZ →YZ for any Z‬‬

‫‪91‬‬

‫تصميم قواعد البيانات‬ ‫الاعتماديات الوظيفية ‪Functional Dependencies‬‬

‫تنص بديهية الزيادة على أن يجب على كل سمة ليست مفتا ًحا ‪ non-key attribute‬الاعتماد على المفت اح‬
‫الرئيسي ‪ PK‬بصورة كاملة‪ ،‬فمثاًل ‪ ،‬تعتمد الس مات التالي ة‪ :‬اس م الط الب ‪ ،StudentName‬والعن وان ‪،Address‬‬
‫والمدينة ‪ ،City‬و‪ ،Prov‬و‪- PC‬أي الرم ز البري دي ‪ -postal code‬على س مة رقم الط الب ‪ StudentNo‬فق ط‪ ،‬ولا‬

‫تعتمد على السمتين ‪ ،StudentNo‬و‪ Grade‬م ًعا‪.‬‬

‫‪StudentNo, Course ——> StudentName, Address, City, Prov, PC, Grade,‬‬
‫‪DateCompleted‬‬
‫هذا الوضع غير مرغوب به لأنه يجب على كل سمة ليس ت مفتا ًح ا الاعتم اد على المفت اح ‪ PK‬تما ًم ا‪ ،‬ولكن‬

‫تعتمد معلومات الطلاب في هذه الحالة جزئ ًيا فقط على المفتاح الرئيسي ‪ PK‬أي ‪.StudentNo‬‬
‫يجب إصلاح هذه المشكلة من خلال تقسيم الجدول الأصلي إلى جدولين على النحو التالي‪:‬‬

‫• الجدول الأول ‪ :1‬يحوي الحقول التالية‪:‬‬
‫◦ ‪StudentNo‬‬
‫◦ ‪Course‬‬
‫◦ ‪Grade‬‬

‫◦ ‪DateCompleted‬‬
‫• الجدول الثاني ‪ :2‬ويحوي الحقول التالية‪:‬‬

‫◦ ‪StudentNo‬‬
‫◦ ‪StudentName‬‬

‫◦ ‪Address‬‬
‫◦ ‪City‬‬
‫◦ ‪Prov‬‬
‫◦ ‪PC‬‬

‫‪ 9.2.3‬البديهية المتعدية ‪Axiom of transitivity‬‬

‫تنص البديهية المتع ِّدية على أنه إذا كانت ‪ X‬تح ِّدد ‪ ،Y‬و‪ Y‬تح ِّدد ‪ ،Z‬فإ ّن ‪ X‬تح ِّدد ‪ Z‬أي ًضا‪:‬‬
‫‪if X →Y ∧Y → Z then X →Z‬‬

‫‪92‬‬

‫تصميم قواعد البيانات‬ ‫الاعتماديات الوظيفية ‪Functional Dependencies‬‬

‫يحت وي الج دول أدن اه على معلوم ات غ ير مرتبط ة مباش ر ًة بالط الب‪ ،‬فيجب أن يك ون لمع رِّف‬
‫البرنامج ‪ ،ProgramID‬واسم البرنامج ‪ ProgramName‬جدواًل خا ًصا بهما‪ ،‬حيث لا يعتمد اسم البرن امج على رقم‬

‫الطالب‪ ،‬وإنما يعتمد على معرِّف البرنامج‪.‬‬

‫‪StudentNo ——> StudentName, Address, City, Prov, PC, ProgramID,‬‬
‫‪ProgramName‬‬

‫هذه الحالة غير مرغوب بها بسبب اعتماد السمة التي ليست مفتا ًحا ‪-‬أي ‪ -ProgramName‬على سمة أخرى‬
‫ليست مفتاحًا أي ًضا ‪-‬أي ‪.-ProgramID‬‬

‫نحل هذه المشكلة من خلال تقسيم هذا الجدول إلى جدولين‪ :‬جدول لمعلومات الطالب‪ ،‬والآخ ر لمعلوم ات‬
‫البرنامج‪ ،‬أي كما يلي‪:‬‬

‫• الجدول ‪:1‬‬

‫‪StudentNo —> StudentName, Address, City, Prov, PC, ProgramID‬‬
‫• الجدول ‪:2‬‬

‫‪ProgramID —> ProgramName‬‬
‫لكن لا ن زال بحاج ة إلى مفت اح خ ارجي ‪ FK‬في ج دول الط الب لنتمكن من تحدي د البرن امج ال ذي ُس جِّل‬

‫الطالب به‪.‬‬

‫‪ 9.2.4‬الاتحاد ‪Union‬‬

‫تشير هذه القاعدة إلى أنه إذا كان جدولان منفصلان‪ ،‬والمفتاح الرئيسي ‪ PK‬هو نفسه‪ ،‬فقد ت رغب في وض ع‬
‫الجدولين م ًعا إذ تنص هذه القاعدة على أنه إذا كانت ‪ X‬تح ِّدد ‪ ،Y‬و‪ X‬تح ِّدد ‪ ،Z‬فيجب على ‪ X‬أن تح ِّدد ‪ Y‬و‪ Z‬أي ًضا‪:‬‬

‫‪if X →Y ∧ X → Z then X →YZ‬‬
‫افترض على سبيل المثال أ ّن‪:‬‬

‫‪SIN ——> EmpName‬‬
‫‪SIN ——> SpouseName‬‬

‫قد ترغب في ضم هذين الجدولين في جدول واحد على النحو التالي‪:‬‬

‫‪SIN ——> EmpName, SpouseName‬‬

‫قد يختار بعض مسؤولي قاع دة البيان ات ‪- database administrators‬أو ‪ DBA‬اختص ا ًرا‪ -‬الاحتف اظ به ذه‬
‫الجداول مفصول ًة لسببين‪ ،‬هما‪ :‬السبب الأول هو أ ّن كل جدول ي ِصف كيانًا مختل ًفا‪ ،‬ل ذلك يجب إبق اء الكيان ات‬

‫‪93‬‬

‫تصميم قواعد البيانات‬ ‫الاعتماديات الوظيفية ‪Functional Dependencies‬‬

‫منفصل ًة عن بعضها البعض‪ ،‬والس بب الث اني ه و إذا تُرِك اس م ال زوج ‪ SpouseName‬فار ًغ ا ‪ NULL‬في معظم‬
‫الأوقات‪ ،‬فلا حاجة إلى تضمينه في نفس جدول اسم المو ّظف ‪.EmpName‬‬

‫‪ 9.2.5‬التفكك ‪Decomposition‬‬

‫التف ُّكك ‪ Decomposition‬هو عكس قاعدة الاتحاد ‪ ،Union‬فإذا كان لديك جدواًل يبدو أنه يحتوي على كيانين‬
‫يح ِّددهما المفتاح الرئيسي ‪ PK‬نفسه‪ ،‬فستفكِّر في تقس يمه إلى ج دولين‪ ،‬حيث تنص ه ذه القاع دة على أن ه إذا‬

‫كانت ‪ X‬تح ِّدد ‪ Y‬و ‪ Z‬م ًعا‪ ،‬فستكون ‪ X‬تح ِّدد ‪ Y‬و ‪ X‬تح ِّدد ‪ Z‬بصور ٍة منفصلة‪:‬‬

‫‪if X →YZ then X →Y ∧X →Z‬‬

‫‪ 9.3‬مخطط الاعتمادية ‪Dependency Diagram‬‬

‫يو ِّضح مخطط الاعتمادية والمب َّين في الشكل الآتي العديد من الاعتماديات المختلفة التي قد تكون موجود ًة‬
‫في جدول لم تط َّب ٍق عليه عملية التوحيد ‪ ،non-normalized table‬أي الجدول الذي يحتوي على تكرار بيانات‪.‬‬
‫تُح َّدد الاعتماديات التالية في هذا الجدول كما يلي‪:‬‬

‫• يتألف المفتاح الأساسي من مجموع ‪ ProjectNo‬و‪.EmpNo‬‬

‫• الاعتماديات الجزئية ‪:PDs‬‬
‫◦ ‪.ProjectNo —> ProjName‬‬
‫◦ ‪.EmpNo —> EmpName, DeptNo‬‬
‫◦ ‪.ProjectNo, EmpNo —> HrsWork‬‬

‫‪94‬‬

‫تصميم قواعد البيانات‬ ‫الاعتماديات الوظيفية ‪Functional Dependencies‬‬

‫• الاعتمادية المتعددية ‪:Transitive Dependency‬‬
‫◦ ‪DeptNo —> DeptName‬‬

‫‪ 9.4‬مصطلحات أساسية‬

‫• بديهيات أرمسترونغ ‪ :Armstrong's Bacioms‬هي مجموعة من قواعد الاستدلال المستخدمة‬
‫لاستنتاج جميع الاعتماديات الوظيفية في قاعدة بيانات علائقية‪.‬‬

‫• ‪ :DBA‬أي ‪ ،database administrator‬وتعني مسؤول قاعدة البيانات‪.‬‬
‫• التفكُّك ‪ :decomposition‬قاعدة تشير إلى أنه إذا كان لديك جدول يبدو أنه يحتوي كيانَين يح ّددهما‬

‫المفتاح الرئيسي ‪ PK‬نفسه‪ ،‬ففكِّر في تقسيمه إلى جدولين‪.‬‬
‫• الاعتمادي ‪ :dependent‬الجانب الأيمن من مخطط الاعتمادية الوظيفية‪.‬‬
‫• المح ِّدد ‪ :determinant‬الجانب الأيسر من مخطط الاعتمادية الوظيفية‪.‬‬
‫• الاعتمادية الوظيفية ‪ functional dependency‬أو ‪ :FD‬علاقة بين سم َتين‪ ،‬عاد ًة ما تكون بين‬

‫المفتاح الرئيسي ‪ PK‬والسمات الأخرى التي ليست مفاتيح داخل جدول‪.‬‬
‫• جدول غير موحد ‪ :non-normalized table‬الجدول الذي يحتوي على تكرار بيانات فيه‪.‬‬
‫• الاتحاد ‪ :Union‬قاعدة تشير إلى أنه إذا كان جدولان منفصلان‪ ،‬ولهما المفتاح الرئيسي ‪ PK‬نفسه‪ ،‬ففكِّر‬

‫في وضعهما م ًعا‪.‬‬

‫‪95‬‬

‫‪ .10‬فهم عملية التوحيد‬

‫‪Normalization‬‬

‫يجب أن يكون التوحيد جز ًءا من عملية تصميم قاعدة البيانات‪ ،‬ولكن من الصعب فصل عملية التوحي د عن‬
‫عملية نمذجة الكيان العلائقي ‪ ،ER modelling‬لذلك يجب استخدام الطريقتين بالتزامن‪.‬‬

‫يُستخ َدم مخطط علاقات الكائنات ‪- entity relation diagram‬أو ‪ ERD‬اختصا ًرا‪ -‬لتوف ير الرؤي ة الكب يرة أو‬
‫الشاملة لمتطلبات بيانات المؤسسة وعملياتها‪ ،‬إذ يَنشأ ذلك من خلال عملية تكراري ة تتض من تحدي د الكيان ات‬
‫المرتبطة‪ ،‬وسماتها‪ ،‬وعلاقاتها؛ بينما ير ِّكز إجراء التوحيد على خصائص كيان ات مح د َّدة‪ ،‬كم ا يم ِّثل رؤي ًة ُمص َّغر ًة‬

‫للكيانات داخل مخطط ‪.ERD‬‬

‫‪ 10.1‬ما هو التوحيد ‪Normalization‬؟‬

‫التوحي د ه و ف رع من ف روع النظري ة العلائقي ة ال ذي ي وفر رؤى التص ميم‪ ،‬وه و عملي ة تحدي د مق دار‬
‫التكرار ‪ redundancy‬الموجود في الجدول‪.‬‬
‫أهداف التوحيد هي‪:‬‬

‫• القدرة على وصف مستوى التكرار في مخطط علائقي‪.‬‬
‫• توفير آليات لتغيير المخططات بهدف إزالة التكرار‪.‬‬

‫تعتمد نظرية التوحيد على نظرية الاعتمادي ات الوظيفي ة اعتم ا ًدا كب يرًا‪ ،‬وتح ِّدد ه ذه النظري ة س تة نم اذج‬
‫موحَّدة ‪- normal forms‬أو ‪ NF‬اختصا ًرا‪ ،-‬حيث يتضمن كل نموذج موحَّد مجموع ًة من خصائص الاعتمادية التي‬
‫يجب أن يفي المخطط بها‪ ،‬كما يعطي كل نموذج موحَّد ض مانات ح ول وج ود ‪ /‬أو ع دم وج ود ح الات تح ديث‬
‫شاذة ‪ ،update anomalies‬وهذا يع ني احت واء النم اذج الموح دة الأعلى على ع دد أق ل من التك رار‪ ،‬وبالت الي‪،‬‬

‫مشاكل تحديث أقل‪.‬‬

‫تصميم قواعد البيانات‬ ‫فهم عملية التوحيد ‪Normalization‬‬

‫‪ 10.2‬النماذج الموحدة ‪Normal Forms‬‬

‫يمكن أن تكون جميع الجداول الموجودة في قواعد البيان ات ض من أح د النم اذج الموحَّدة ال تي سنناقش ها‬
‫الآن‪ .‬نريد الحد الأدنى من التكرار بين المفتاح الرئيسي ‪ ،PK‬والمفتاح الخارجي ‪ FK‬من الناحية المثالية‪ ،‬كما يجب‬

‫اشتقاق كل شيء آخر من جداول أخرى‪.‬‬

‫هناك ستة نماذج موحَّدة‪ ،‬ولكننا سنلقي نظرة على النماذج الأربعة الأولى فقط‪ ،‬وهي‪:‬‬
‫• النموذج الموحَّد الأول ‪ ،First normal form‬أو ‪ 1NF‬اختصا ًرا‪.‬‬

‫• النموذج الموحَّد الثاني ‪ ،Second normal form‬أو ‪ 2NF‬اختصا ًرا‪.‬‬
‫• النموذج الموحَّد الثالث ‪ ،Third normal form‬أو ‪ 3NF‬اختصا ًرا‪.‬‬

‫• نموذج بويس‪-‬كود الموحَّد ‪ ،Boyce-Codd normal form‬أو ‪ BCNF‬اختصا ًرا‪ ،‬وهو نادر الاستخدام‪.‬‬

‫‪ 10.3‬النموذج الموحد الأول ‪ First Normal Form‬أو ‪ 1NF‬اختصا ًرا‬

‫يُس َمح فقط بقيم غير مكرَّرة في النموذج الموحد الأول عند تقاطع ك ل ص ف وعم ود‪ ،‬وه ذا ي ؤدي إلى ع دم‬
‫وجود مجموعات مكرَّرة ‪ ،repeating group‬حيث يجب إزالة المجموع ة المك رَّرة‪ ،‬وتش كيل علاق تين جدي دتين‬
‫لتوحيد علاقة تحتوي على مجموعة مكرَّرة‪ ،‬ويكون المفتاح الرئيسي ‪ PK‬للعلاقة الجديدة ه و ت ركيب من المفت اح‬

‫الرئيسي ‪ PK‬للعلاقة الأصلية بالإضافة إلى سمة من العلاقة المن َشأة حدي ًثا للحصول على تعريف فريد‪.‬‬

‫‪ 10.3.1‬عملية نموذج ‪1NF‬‬

‫سنس تخدم ج دول تقري ر درج ات الط الب ‪ Student_Grade_Report‬أدن اه‪ ،‬من قاع دة بيان ات المدرس ة‬
‫‪ School‬على أساس مثال لشرح عملية نموذج ‪.1NF‬‬

‫‪**Student_Grade_Report** (StudentNo, StudentName, Major, CourseNo,‬‬
‫)‪CourseName, InstructorNo, InstructorName, InstructorLocation, Grade‬‬

‫• تكون المجموعة المكرَّرة في ج دول تقري ر درج ات الط الب ‪ Student Grade Report‬هي معلوم ات‬
‫المقرر الدراسي ‪ ،course‬إذ يمكن للطالب أخذ مقررات متعددة‪.‬‬

‫• أزِل المجموعة المكر َّرة‪ ،‬إذ إن المجموعة المكرَّرة في هذه الحالة هي معلومات المقرر لكل طالب‪.‬‬
‫• ح ِّدد المفتاح الرئيسي ‪ PK‬لجدولك الجديد‪.‬‬

‫• يجب أن يح ِّدد المفتاح الرئيسي ‪ PK‬قيم َة السمة ‪ StudentNo‬و‪ CourseNo‬تحدي ًدا فري ًدا‪.‬‬
‫• يبقى جدول مقررات الطلاب ‪ StudentCourse‬بعد إزالة جميع السمات المتعلِّقة بالمقرر والطالب‪.‬‬

‫‪97‬‬

‫تصميم قواعد البيانات‬ ‫فهم عملية التوحيد ‪Normalization‬‬

‫• أصبح جدول الطالب ‪ Student‬الآن بصيغة النموذج الموحَّد الأول مع إزالة المجموعة المكرَّرة‪.‬‬
‫• الجدولان الجديدان مو َّضحان كما يلي‪:‬‬

‫)‪Student (StudentNo, StudentName, Major‬‬

‫‪StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo,‬‬
‫)‪InstructorName, InstructorLocation, Grade‬‬

‫‪ 10.3.2‬كيفية تحديث حالات نموذج ‪ 1NF‬الشاذة‬

‫بالنظر إلى الجدولين السابقين‪:‬‬
‫• نحتاج طال ًبا لإضافة مقرَّر جديد‪.‬‬
‫• قد يكون لدينا تناقضات عندما تحتاج معلومات المقرَّر إلى تحديث‪.‬‬
‫• قد نحذف أي ًضا معلومات هامة حول مقرر عند حذف طالب‪.‬‬

‫‪ 10.4‬النموذج الموحد الثاني ‪ Second Normal Form‬أو ‪2NF‬‬

‫يجب أن تك ون العلاق ة أواًل بص يغة نم وذج ‪ 1NF‬للانتق ال إلى النم وذج الموحَّد الث اني ‪ ،2NF‬حيث تك ون‬
‫العلاقة تلقائ ًيا بصيغة نموذج ‪ 2NF‬إذا وفقط إذا اشتمل المفتاح الرئيسي ‪ PK‬على سمة واحدة‪.‬‬

‫إذا احتوت العلاقة على مفتاح رئيسي مر ّكب ‪ ،composite PK‬فيجب أن تعتمد ك ل س م ٍة ليس ت مفتاحً ا‬
‫على المفتاح الرئيسي ‪ PK‬بأكمله اعتما ًدا كاماًل ‪ ،‬ولا تعتمد على مجموع ة فرعي ة من المفت اح الرئيس ي ‪ ،PK‬أي لا‬

‫يجب وجود اعتمادية جزئية ‪ ،partial dependency‬أو ما يُس َّمى بالزيادة ‪.augmentation‬‬

‫‪ 10.4.1‬عملية نموذج ‪2NF‬‬

‫يجب أواًل أن يكون الجدول بصيغة نموذج ‪ 1NF‬للانتقال إلى النموذج ‪.2NF‬‬
‫• جدول الطالب ‪ Student‬موجود بالفعل بصيغة نموذج ‪ 2NF‬لأنه يحتوي على عمود مفتاح رئيس ي واح د‬

‫فقط بالفعل‪.‬‬
‫• ليست كل السمات ‪-‬وتحدي ًدا جمي ع معلوم ات المق رر ‪ -course information‬معتم د ًة بالكام ل على‬
‫المفت اح الرئيس ي عن د فحص ج دول مق ررات الطلاب ‪ ،Student Course‬إذ تك ون الس مة الوحي دة‬

‫المعتمدة بالكامل على المفتاح الرئيسي هي الدرجة ‪.grade‬‬
‫• عرِّف الجدول الجديد الذي يحتوي على معلومات المقرَّر‪.‬‬

‫‪98‬‬

‫تصميم قواعد البيانات‬ ‫فهم عملية التوحيد ‪Normalization‬‬

‫• عرِّف المفتاح الرئيسي ‪ PK‬للجدول الجديد‪.‬‬
‫• الجداول الثلاثة الجديدة مو َّضحة أدناه‪.‬‬

‫)‪Student (StudentNo, StudentName, Major‬‬

‫)‪CourseGrade (StudentNo, CourseNo, Grade‬‬

‫‪CourseInstructor (CourseNo, CourseName, InstructorNo, InstructorName,‬‬
‫)‪InstructorLocation‬‬

‫‪ 10.4.2‬كيفية تحديث حالات نموذج ‪ 2NF‬الشاذة‬

‫بالنظر إلى الجداول الثلاثة السابقة‪:‬‬
‫• نحتاج إلى مقرَّر ‪ course‬عند إضافة مدرِّس جديد‪.‬‬
‫• قد يؤدي تحديث معلومات المقرر إلى وجود تناقضات في معلومات المدرِّس‪.‬‬
‫• قد يؤدي حذف المقرر أي ًضا إلى حذف معلومات المدرِّس‪.‬‬

‫‪ 10.5‬النموذج الموحد الثالث ‪ Third Normal Form‬أو ‪3NF‬‬

‫يجب أن تكون العلاقة بصيغة النموذج الموحَّد الثاني ‪ 2NF‬للانتقال إلى النم وذج الموحَّد الث الث ‪ ،3NF‬كم ا‬
‫يجب إزالة جميع الاعتماديات المتعدية ‪ transitive dependencies‬أي ًضا‪ ،‬فق د لا تعتم د الس مة ال تي ليس ت‬

‫مفتا ًحا اعتما ًدا وظيف ًيا على سمة أخرى ليست مفتا ًحا‪.‬‬

‫‪ 10.5.1‬عملية نموذج ‪3NF‬‬

‫• أزِل كافة السمات الاعتمادية ‪ dependent attributes‬في العلاق ة‪ ،‬أو في العلاق ات المتعدي ة من ك ل‬
‫جدول من الجداول التي لها علاقة متعدية‪.‬‬

‫• أن ِشئ جدواًل ‪ ،‬أو جداول جديدة مع إزالة الاعتمادية‪.‬‬
‫• تحقق من الجدول أو الجداول الجديدة‪ ،‬كما تحقق من الجدول أو الجداول المع َّدلة أي ًضا وذلك للتأكد من‬

‫احتواء كل جدول على مح ِّدد ‪ determinant‬ومن عدم وجود جدول يحتوي على اعتماديات غير مناسبة‪.‬‬
‫• الجداول الأربعة الجديدة مو َّضحة أدناه‪.‬‬

‫‪99‬‬

‫تصميم قواعد البيانات‬ Normalization ‫فهم عملية التوحيد‬
Student (StudentNo, StudentName, Major)

CourseGrade (StudentNo, CourseNo, Grade)

Course (CourseNo, CourseName, InstructorNo)

Instructor (InstructorNo, InstructorName, InstructorLocation)

.‫يجب ألا تكون هناك حالات شاذة في النموذج الموحَّد الثالث في هذه المرحلة‬
‫ حيث تتمث ل الخط وة الأولى في‬،‫لنل ِق نظر ًة على مخطط الاعتمادية المو َّضح في الشكل الآتي له ذا المث ال‬

.‫إزالة المجموعات المكرَّرة‬

Student (StudentNo, StudentName, Major)
StudentCourse (StudentNo, CourseNo, CourseName, InstructorNo,
InstructorName, InstructorLocation, Grade)

‫ قاع دة بيان ات‬normalization ‫تلخِّص الاعتمادي ات المو َّض حة في الش كل الت الي عملي ة توحي د‬
:School database ‫المدرسة‬

:‫الاختصارات المستخدمة في الشكل السابق هي كما يلي‬
.partial dependency ‫ الاعتمادية الجزئية‬:PD •

.transitive dependency ‫ الاعتمادية المتعدية‬:TD •

100