نموذج الكيان والعلاقة المحسن وتصميم قواعد البيانات العلائقية
تغطي هذه الوحدة نموذج الكيان والعلاقة المحسن (EER)، بما في ذلك التخصيص، التعميم، الفئات، وقيودها. كما تشرح بالتفصيل خوارزمية تحويل مخططات ER و EER إلى جداول علائقية.
Enhanced Entity-Relationship Model and Relational Database Design
This module covers the Enhanced Entity-Relationship (EER) model, including specialization, generalization, categories, and their constraints. It also details the algorithm for mapping ER and EER schemas to relational tables.
أهداف التعلم
- شرح مفاهيم نموذج الكيان والعلاقة المحسن (EER).
- تطبيق قيود الانفصال والاكتمال على التخصيص والتعميم.
- نمذجة أنواع الاتحاد (Union Types) باستخدام الفئات (Categories).
- تحويل مخططات ER إلى مخططات قواعد بيانات علائقية باستخدام خوارزمية من 7 خطوات.
- تحويل مفاهيم EER (التخصيص والفئات) إلى جداول علائقية.
- Explain the Enhanced Entity-Relationship (EER) Model.
- Apply disjointness and completeness constraints to specialization and generalization.
- Model UNION types using Categories.
- Map ER schemas to relational database schemas using a 7-step algorithm.
- Map EER constructs (specialization and categories) to relational tables.
1 التخصيص والتعميم (Specialization & Generalization)
1 Specialization & Generalization
التخصيص هو تقسيم كيان عام إلى كيانات فرعية متخصصة (من أعلى لأسفل)، بينما التعميم هو تجميع كيانات مشتركة في كيان عام (من أسفل لأعلى).
Specialization is splitting a general entity into specific sub-entities (top-down), while generalization is grouping common entities into a general one (bottom-up).
في نموذج EER، التخصيص (Specialization) هو عملية تعريف مجموعة من الفئات الفرعية (Subclasses) لنوع كيان معين (Superclass) بناءً على خصائص مميزة. إنها عملية تحسين مفاهيمية من أعلى إلى أسفل (Top-down). على سبيل المثال، يمكن تخصيص الكيان EMPLOYEE إلى SECRETARY, TECHNICIAN, ENGINEER.
التعميم (Generalization) هو العملية العكسية؛ حيث نبدأ بأنواع كيانات متعددة ونقوم بتعميمها في كيان أعلى (Superclass) يجمع الخصائص المشتركة (Bottom-up). ترث الفئة الفرعية جميع السمات والعلاقات الخاصة بالفئة العليا.
In the EER model, Specialization is the process of defining a set of subclasses of an entity type (the superclass) based on distinguishing characteristics. It is a top-down conceptual refinement process. For example, EMPLOYEE can be specialized into SECRETARY, TECHNICIAN, and ENGINEER.
Generalization is the reverse process; starting with many entity types and generalizing those that have common properties into a single superclass (bottom-up). A subclass inherits all attributes and relationships of its superclass.
التعميم عادة ما يكون كلياً (Total) لأن الفئة العليا تُشتق أساساً من الفئات الفرعية الموجودة.
التخصيص يسمح بنمذجة دقيقة للبيانات حيث يمكن أن تشارك الفئات الفرعية في علاقات لا تنطبق على الفئة العليا بأكملها. هذا يقلل من القيم الفارغة (Nulls) في قاعدة البيانات ويزيد من دقة القيود الدلالية.
Generalization is usually total because the superclass is derived directly from the subclasses.
Specialization allows for precise data modeling where subclasses can participate in relationships that do not apply to the entire superclass. This reduces Null values in the database and increases the precision of semantic constraints.
لماذا نستخدم التخصيص بدلاً من وضع جميع السمات في كيان واحد كبير مع ترك بعضها فارغاً (Null)؟ Why use specialization instead of putting all attributes in one large entity and leaving some as Null?
التخصيص يمنع إهدار المساحة بالقيم الفارغة، ويسمح بتعريف علاقات محددة تنطبق فقط على فئات فرعية معينة، مما يعكس قواعد العمل (Business Rules) بدقة أكبر.
Specialization prevents wasted space with Null values and allows defining specific relationships that apply only to certain subclasses, reflecting business rules more accurately.
2 قيود التخصيص والتعميم (Constraints)
2 Constraints on Specialization and Generalization
قيد الانفصال يحدد ما إذا كان الكيان ينتمي لفئة فرعية واحدة فقط (Disjoint) أو أكثر (Overlapping). قيد الاكتمال يحدد ما إذا كان يجب أن ينتمي الكيان لفئة فرعية (Total) أم لا (Partial).
Disjointness constraint determines if an entity belongs to at most one subclass (Disjoint) or multiple (Overlapping). Completeness constraint determines if an entity MUST belong to a subclass (Total) or NOT (Partial).
يوجد قيدان أساسيان يطبقان على التخصيص/التعميم:
- قيد الانفصال (Disjointness Constraint): يحدد ما إذا كانت الفئات الفرعية منفصلة. إذا كانت منفصلة (Disjoint - يُرمز لها بـ d)، فإن الكيان يمكن أن يكون عضواً في فئة فرعية واحدة على الأكثر. إذا لم تكن منفصلة (Overlapping - يُرمز لها بـ o)، يمكن للكيان أن ينتمي لأكثر من فئة فرعية في نفس الوقت.
- قيد الاكتمال (Completeness Constraint): يحدد ما إذا كان كل كيان في الفئة العليا يجب أن يكون عضواً في فئة فرعية على الأقل. إذا كان كلياً (Total - خط مزدوج)، يجب أن ينتمي الكيان لفئة فرعية. إذا كان جزئياً (Partial - خط مفرد)، يُسمح للكيان بألا ينتمي لأي فئة فرعية.
Two basic constraints apply to specialization/generalization:
- Disjointness Constraint: Specifies whether the subclasses are disjoint. If disjoint (specified by 'd'), an entity can be a member of at most one subclass. If overlapping (specified by 'o'), the same entity may be a member of more than one subclass.
- Completeness Constraint: Specifies whether every entity in the superclass must be a member of some subclass. Total completeness (shown by a double line) means every entity MUST belong to a subclass. Partial completeness (single line) allows an entity not to belong to any subclass.
ينتج عن هذين القيدين أربعة أنواع من التخصيص: (Disjoint, Total), (Disjoint, Partial), (Overlapping, Total), (Overlapping, Partial). الوضع الافتراضي (Default) في غياب القيود الصريحة هو (Overlapping, Partial).
رياضياً، في التخصيص الكلي (Total)، اتحاد الفئات الفرعية يساوي الفئة العليا (S1 U S2 ... U Sn = G). وفي التخصيص المنفصل (Disjoint)، تقاطع أي فئتين فرعيتين يساوي مجموعة خالية.
These constraints yield four types of specialization: (Disjoint, Total), (Disjoint, Partial), (Overlapping, Total), and (Overlapping, Partial). The default is overlapping, partial.
Formally, for a total specialization Z of G, S1 U S2 U ... U Sn = G. For a disjoint specialization, (Si ∩ Sj) = empty-set for i ≠ j.
| Disjoint (d) | Overlapping (o) | |
|---|---|---|
| الانتماء للفئات الفرعيةSubclass Membership | فئة فرعية واحدة على الأكثرAt most one subclass | يمكن أن ينتمي لأكثر من فئة فرعيةCan belong to more than one subclass |
| الرمز في مخطط EERSymbol in EER Diagram | حرف 'd' داخل دائرة'd' inside a circle | حرف 'o' داخل دائرة'o' inside a circle |
| خيار التحويل المفضل (جدول واحد)Preferred Single-Table Mapping | الخيار 8C (سمة نوع واحدة)Option 8C (Single type attribute) | الخيار 8D (سمات منطقية متعددة)Option 8D (Multiple boolean attributes) |
هل يمكن أن يكون لدينا تخصيص (Overlapping, Total)؟ أعط مثالاً. Can we have an (Overlapping, Total) specialization? Give an example.
نعم. مثال: كيان 'جزء' (PART) يجب أن يكون إما 'مُصنّع' (MANUFACTURED_PART) أو 'مُشترى' (PURCHASED_PART) أو كليهما (يُصنع محلياً ويُشترى أيضاً لتلبية الطلب).
Yes. Example: A PART entity must be either a MANUFACTURED_PART, a PURCHASED_PART, or both (manufactured in-house but also purchased to meet demand).
3 الفئات وأنواع الاتحاد (Categories / UNION Types)
3 Categories (UNION Types)
الفئة (Category) هي فئة فرعية تمثل اتحاداً (Union) لعدة فئات عليا مختلفة، حيث يجب أن يوجد الكيان في فئة عليا واحدة على الأقل.
A Category is a subclass that represents a UNION of multiple distinct superclasses, where an entity must exist in at least one of its superclasses.
في بعض الحالات، نحتاج إلى نمذجة علاقة فئة عليا/فئة فرعية واحدة مع أكثر من فئة عليا واحدة، حيث تمثل الفئات العليا أنواع كيانات مختلفة. تُسمى هذه الفئة الفرعية الفئة (Category) أو نوع الاتحاد (UNION TYPE).
على سبيل المثال، في قاعدة بيانات تسجيل المركبات، يمكن أن يكون المالك (OWNER) إما شخصاً (PERSON)، أو بنكاً (BANK)، أو شركة (COMPANY). يتم إنشاء الفئة OWNER لتمثيل مجموعة فرعية من اتحاد هذه الكيانات الثلاثة. يُرمز لها في مخطط EER بحرف 'U' داخل دائرة.
In some cases, we need to model a single superclass/subclass relationship with more than one superclass, where the superclasses represent different entity types. Such a subclass is called a Category or UNION TYPE.
For example, a vehicle OWNER can be a PERSON, a BANK, or a COMPANY. A category OWNER is created to represent a subset of the union of the three superclasses. It is denoted by a 'U' in a circle in EER diagrams.
الفرق الجوهري بين الفئة (Category) والفئة الفرعية المشتركة (Shared Subclass) هو أن الفئة الفرعية المشتركة هي مجموعة فرعية من تقاطع (Intersection) فئاتها العليا (أي يجب أن ينتمي الكيان إلى جميع الفئات العليا)، بينما الفئة هي مجموعة فرعية من اتحاد (Union) فئاتها العليا (أي يجب أن ينتمي الكيان إلى واحدة على الأقل من الفئات العليا).
عند تحويل الفئة إلى جداول علائقية، غالباً ما نستخدم مفتاحاً بديلاً (Surrogate Key) لأن الفئات العليا قد تمتلك مفاتيح أساسية مختلفة.
The key difference between a Category and a Shared Subclass is that a shared subclass is a subset of the intersection of its superclasses (member must exist in ALL superclasses), whereas a category is a subset of the union of its superclasses (member must exist in AT LEAST ONE superclass).
When mapping a category to relational tables, a surrogate key is often created because the defining superclasses usually have different primary keys.
| Shared Subclass | Category (UNION Type) | |
|---|---|---|
| العلاقة المنطقيةLogical Relationship | تقاطع (Intersection) الفئات العلياIntersection of superclasses | اتحاد (Union) الفئات العلياUnion of superclasses |
| شرط الانتماءMembership Condition | يجب أن يوجد في *جميع* الفئات العلياMust exist in ALL superclasses | يجب أن يوجد في *واحدة على الأقل* من الفئات العلياMust exist in AT LEAST ONE superclass |
| المفاتيح الأساسية للفئات العلياSuperclass Primary Keys | يجب أن تمتلك جميع الفئات العليا نفس المفتاح الأساسيAll superclasses must have the same key attribute | يمكن أن تمتلك الفئات العليا مفاتيح مختلفة (يتطلب مفتاح بديل)Superclasses can have different keys (requires surrogate key) |
لماذا نحتاج إلى مفتاح بديل (Surrogate Key) عند تحويل الفئة (Category) إلى جدول علائقي؟ Why do we need a surrogate key when mapping a Category to a relational table?
لأن الفئات العليا التي تشكل الفئة (مثل PERSON و BANK) تمتلك مفاتيح أساسية مختلفة (مثل SSN و Bname). لربطها في جدول واحد (OWNER)، نحتاج إلى مفتاح موحد جديد يمثل أي نوع من الملاك.
Because the superclasses forming the category (e.g., PERSON and BANK) have different primary keys (e.g., SSN and Bname). To link them in a single OWNER table, a new uniform key is needed to represent any type of owner.
4 خوارزمية التحويل من ER إلى نموذج علائقي (ER-to-Relational Mapping)
4 ER-to-Relational Mapping Algorithm
خوارزمية من 7 خطوات لتحويل مخطط ER إلى جداول: الكيانات القوية، الكيانات الضعيفة، علاقات 1:1، 1:N، M:N، السمات متعددة القيم، والعلاقات الثلاثية فأكثر.
A 7-step algorithm to convert ER diagrams to tables: Regular entities, Weak entities, 1:1, 1:N, M:N relationships, Multivalued attributes, and n-ary relationships.
تتكون خوارزمية التحويل الأساسية من 7 خطوات:
- الخطوة 1: الكيانات العادية (القوية) تُحول إلى جداول، ويُختار أحد المفاتيح كمفتاح أساسي (PK).
- الخطوة 2: الكيانات الضعيفة تُحول إلى جداول، ويكون مفتاحها الأساسي هو مزيج من المفتاح الأساسي للكيان المالك والمفتاح الجزئي للكيان الضعيف.
- الخطوة 3: علاقات 1:1 تُعالج غالباً بإضافة مفتاح أجنبي (Foreign Key) في الكيان ذي المشاركة الكلية (Total Participation).
- الخطوة 4: علاقات 1:N تُعالج بوضع مفتاح أجنبي في جدول الكيان الموجود في جهة الـ N.
- الخطوة 5: علاقات M:N تتطلب إنشاء جدول جديد (Relationship relation) يحتوي على المفاتيح الأساسية للكيانين كمفاتيح أجنبية، ومزيجهما يشكل المفتاح الأساسي للجدول الجديد.
- الخطوة 6: السمات متعددة القيم (Multivalued) تُحول إلى جدول جديد يحتوي على السمة والمفتاح الأجنبي للكيان الأصلي.
- الخطوة 7: العلاقات من الدرجة n (n-ary) تُحول إلى جدول جديد يحتوي على المفاتيح الأجنبية لجميع الكيانات المشاركة.
The basic mapping algorithm consists of 7 steps:
- Step 1: Regular (strong) entities become relations. Choose one key as the Primary Key (PK).
- Step 2: Weak entities become relations. The PK is the combination of the owner's PK and the weak entity's partial key.
- Step 3: Binary 1:1 relationships are usually mapped using the Foreign Key approach (placed in the entity with total participation).
- Step 4: Binary 1:N relationships are mapped by placing a foreign key in the relation on the N-side.
- Step 5: Binary M:N relationships require creating a new relation (cross-reference) containing the PKs of participating entities as foreign keys. Their combination forms the new PK.
- Step 6: Multivalued attributes get their own relation containing the attribute and a foreign key to the parent entity.
- Step 7: N-ary relationships (n>2) are mapped to a new relation containing foreign keys from all participating entities.
في الخطوة 3 (علاقات 1:1)، يوجد ثلاثة خيارات: نهج المفتاح الأجنبي (الأفضل)، نهج دمج الجداول (إذا كانت المشاركة كلية من الطرفين)، ونهج جدول العلاقة المتقاطع (Cross-reference).
في الخطوة 5 (M:N)، لا يمكن استخدام المفتاح الأجنبي المباشر لأن ذلك سيؤدي إلى تكرار البيانات أو قيم متعددة في حقل واحد، وهو ما ينتهك الشكل الطبيعي الأول (1NF) في قواعد البيانات العلائقية.
In Step 3 (1:1), there are three options: Foreign Key approach (preferred), Merged relation option (if both participations are total), and Cross-reference option.
In Step 5 (M:N), the foreign key approach cannot be used because it would require multi-valued fields or massive data duplication, violating the First Normal Form (1NF) of the relational model.
لماذا نضع المفتاح الأجنبي في جهة الـ N في علاقة 1:N بدلاً من جهة الـ 1؟ Why do we place the foreign key on the N-side in a 1:N relationship instead of the 1-side?
لأن وضع المفتاح الأجنبي في جهة الـ 1 سيتطلب تخزين قيم متعددة (قائمة من المفاتيح) في حقل واحد، وهو ما لا يدعمه النموذج العلائقي الأساسي (ينتهك 1NF).
Because placing the foreign key on the 1-side would require storing multiple values (a list of keys) in a single field, which is not supported by the basic relational model (violates 1NF).
5 تحويل مفاهيم EER إلى جداول (EER Mapping Steps 8 & 9)
5 Mapping EER Model Constructs (Steps 8 & 9)
الخطوة 8 تتعامل مع التخصيص/التعميم بأربعة خيارات (جداول متعددة أو جدول واحد). الخطوة 9 تتعامل مع الفئات (Categories) باستخدام مفتاح بديل.
Step 8 handles specialization/generalization with 4 options (multiple tables or single table). Step 9 handles Categories using a surrogate key.
تُضاف خطوتان لخوارزمية التحويل للتعامل مع EER:
- الخطوة 8: تحويل التخصيص/التعميم. يوجد 4 خيارات:
- 8A: جداول متعددة (جدول للفئة العليا وجدول لكل فئة فرعية). يعمل مع أي تخصيص.
- 8B: جداول للفئات الفرعية فقط. يعمل جيداً إذا كان التخصيص كلياً (Total) ومنفصلاً (Disjoint).
- 8C: جدول واحد مع سمة نوع (Type attribute) واحدة. يعمل فقط مع الفئات الفرعية المنفصلة (Disjoint).
- 8D: جدول واحد مع سمات نوع متعددة (Boolean attributes). يعمل مع الفئات الفرعية المتداخلة (Overlapping).
- الخطوة 9: تحويل الفئات (UNION Types). يتم إنشاء جدول جديد للفئة، وبما أن الفئات العليا قد تمتلك مفاتيح مختلفة، يتم إنشاء مفتاح بديل (Surrogate Key) ليكون المفتاح الأساسي لجدول الفئة، ويُضاف كمفتاح أجنبي في جداول الفئات العليا.
Two steps are added to handle EER constructs:
- Step 8: Mapping Specialization/Generalization. There are 4 options:
- 8A: Multiple relations (Superclass and subclasses). Works for any specialization.
- 8B: Multiple relations (Subclass relations only). Works best for total and disjoint subclasses.
- 8C: Single relation with one type attribute. Works for disjoint subclasses.
- 8D: Single relation with multiple type (boolean) attributes. Works for overlapping subclasses.
- Step 9: Mapping Union Types (Categories). A new relation is created for the category. Since defining superclasses may have different keys, a Surrogate Key is created as the PK for the category relation and added as a foreign key to the superclass relations.
اختيار الخيار المناسب في الخطوة 8 يعتمد على القيود. الخيار 8C (جدول واحد) يقلل من عمليات الربط (JOINs) عند الاستعلام، ولكنه قد يؤدي إلى العديد من القيم الفارغة (NULLs) إذا كانت الفئات الفرعية تمتلك سمات كثيرة غير مشتركة.
الخيار 8A يحافظ على نظافة البيانات (بدون NULLs) ولكنه يتطلب عمليات ربط مكلفة لاسترجاع بيانات الكيان كاملة.
Choosing the right option in Step 8 depends on constraints. Option 8C (single table) reduces JOIN operations during queries but can lead to many NULL values if subclasses have many specific attributes.
Option 8A keeps data clean (no NULLs) but requires costly JOINs to retrieve a complete entity's data.
لماذا لا يمكن استخدام الخيار 8C (سمة نوع واحدة) مع الفئات الفرعية المتداخلة (Overlapping)؟ Why can't Option 8C (single type attribute) be used with overlapping subclasses?
لأن الكيان في التخصيص المتداخل يمكن أن ينتمي لأكثر من فئة فرعية في نفس الوقت، وسمة النوع الواحدة لا يمكنها تخزين قيم متعددة (إلا إذا كسرنا 1NF). لذلك نستخدم الخيار 8D (سمات منطقية متعددة).
Because an entity in an overlapping specialization can belong to multiple subclasses simultaneously, and a single type attribute cannot store multiple values (without violating 1NF). Thus, Option 8D (multiple boolean attributes) is used.