نموذج الكيانات والعلاقات (الجزء الثاني) والنموذج الموسع (EER)
تغطية متقدمة لنموذج الكيانات والعلاقات تشمل القيود، صيغة (min, max)، مخططات UML، العلاقات من درجات عليا، ومفاهيم النموذج الموسع مثل التخصيص والتعميم والوراثة.
Entity-Relationship Model-2 and EER Model
Advanced coverage of the ER model including constraints, (min, max) notation, UML class diagrams, higher-degree relationships, and EER concepts like specialization, generalization, and inheritance.
أهداف التعلم
- تحديد وتطبيق قيود العلاقات (نسبة التعددية والاعتمادية) باستخدام صيغة (min, max).
- تحويل مفاهيم ER الأساسية إلى مخططات فئات UML (UML Class Diagrams).
- تصميم وتحليل العلاقات ذات الدرجات العليا (الثلاثية وما فوق) ومعرفة متى لا يمكن استبدالها بعلاقات ثنائية.
- استخدام نموذج EER لتمثيل الفئات العليا والفرعية (Superclasses/Subclasses) وتطبيق مبدأ الوراثة.
- التمييز بين عمليتي التخصيص (Specialization) والتعميم (Generalization) في تصميم قواعد البيانات.
- Identify and apply relationship constraints (cardinality ratio and existence dependency) using (min, max) notation.
- Translate basic ER concepts into UML Class Diagrams.
- Design and analyze higher-degree relationships (ternary and n-ary) and understand when they cannot be replaced by binary relationships.
- Use the EER model to represent Superclasses and Subclasses and apply the principle of attribute inheritance.
- Distinguish between Specialization and Generalization processes in database design.
1 قيود العلاقات (Relationship Constraints)
1 Constraints on Relationships
هي القواعد التي تحدد عدد مرات مشاركة الكيان في العلاقة، مثل الحد الأقصى (Cardinality) والحد الأدنى (Participation).
Rules defining how many times an entity can participate in a relationship, specifically maximum (Cardinality) and minimum (Participation).
توجد نوعان رئيسيان من القيود على العلاقات الثنائية:
- نسبة التعددية (Cardinality Ratio): تحدد الحد الأقصى للمشاركة (1:1، 1:N، M:N).
- قيد الاعتمادية/المشاركة (Existence Dependency/Participation): يحدد الحد الأدنى للمشاركة، إما صفر (مشاركة اختيارية) أو واحد فأكثر (مشاركة إلزامية/كلية).
There are two main types of constraints on binary relationships:
- Cardinality Ratio: specifies maximum participation (1:1, 1:N, M:N).
- Existence Dependency (Participation constraint): specifies minimum participation, either zero (optional) or one or more (mandatory/total participation).
هذه القيود مستمدة من المعنى الحقيقي (real-world meaning) للبيانات. المشاركة الكلية تُرسم بخط مزدوج، والجزئية بخط مفرد.
فهم هذه القيود ضروري جداً لاحقاً عند تحويل مخطط ER إلى جداول (Relational Mapping)، حيث تحدد أين نضع المفاتيح الأجنبية (Foreign Keys) وكيف نتعامل مع القيم الفارغة (NULLs).
These constraints are derived from the real-world meaning of the mini-world. Total participation is drawn with a double line, partial with a single line.
Understanding these is critical for the Relational Mapping phase, as they dictate foreign key placement and NULL constraints.
إذا كان الموظف يجب أن يعمل في قسم واحد، والقسم يمكن أن يضم عدة موظفين، فما هي القيود على كلا الجانبين؟ If an employee must work in exactly one department, and a department can have many employees, what are the constraints on both sides?
الموظف: مشاركة كلية (إلزامية) والحد الأقصى 1. القسم: مشاركة جزئية (اختيارية) والحد الأقصى N.
Employee: Total (mandatory) participation, max 1. Department: Partial (optional) participation, max N.
2 صيغة (min, max)
2 Alternative (min, max) Notation
طريقة بديلة لتمثيل القيود بوضع زوج من الأرقام (الأدنى، الأقصى) على خط العلاقة بجوار الكيان.
An alternative way to specify constraints by placing a pair of numbers (min, max) on the relationship line next to the entity.
تحدد هذه الصيغة أن كل كيان e في الفئة E يشارك في العلاقة R بحد أدنى (min) وحد أقصى (max) من المرات. القيمة الافتراضية هي (0, n).
يجب أن يكون min ≤ max، و min ≥ 0، و max ≥ 1. مثال: (1,1) تعني مشاركة إلزامية لمرة واحدة فقط.
Specifies that each entity e in E participates in at least min and at most max relationship instances in R. Default is (0, n).
Must have min ≤ max, min ≥ 0, max ≥ 1. Example: (1,1) means exactly one mandatory participation.
هذه الصيغة تدمج قيدي التعددية والمشاركة في شكل واحد أكثر دقة.
من المهم جداً الانتباه إلى أن بعض المخططات (مثل UML) تعكس مكان وضع هذه الأرقام (تضعها على الجانب الآخر من العلاقة)، مما قد يسبب ارتباكاً كبيراً للمصممين.
This notation jointly specifies cardinality and participation constraints.
Crucially, in some popular notations like UML, the placement of (min, max) is reversed (placed on the opposite side of the binary relationship), which is a common source of errors in database design.
ماذا يعني القيد (0, 1) لكيان الموظف في علاقة 'يدير' (MANAGES)؟ What does the constraint (0, 1) mean for an EMPLOYEE entity in a MANAGES relationship?
يعني أن الموظف قد لا يدير أي قسم (0)، وإذا أدار، فإنه يدير قسماً واحداً كحد أقصى (1).
It means an employee might not manage any department (0), and if they do, they manage at most one department (1).
3 العلاقات العودية وخصائص العلاقات
3 Recursive Relationships & Relationship Attributes
العلاقة العودية تربط الكيان بنفسه بأدوار مختلفة، وخصائص العلاقة هي بيانات تُحفظ على العلاقة نفسها (غالباً في علاقات M:N).
A recursive relationship connects an entity to itself in different roles. Relationship attributes store data on the relationship itself (mostly M:N).
العلاقات العودية: يشارك نفس الكيان في العلاقة بأدوار مختلفة (مثل موظف يدير موظفاً آخر). يجب كتابة 'أسماء الأدوار' (Role Names) على الخطوط لتمييز المشاركات.
خصائص العلاقات: يمكن أن تمتلك العلاقة خصائص (مثل عدد الساعات في علاقة 'يعمل_على'). تُستخدم غالباً مع علاقات M:N، أما في علاقات 1:N فيمكن نقل الخاصية إلى الكيان في جهة N.
Recursive Relationships: Both participations are the same entity type in different roles (e.g., EMPLOYEE as boss and subordinate). Role names must be displayed to distinguish them.
Relationship Attributes: Relationships can have attributes (e.g., HoursPerWeek). Most are used with M:N relationships. In 1:N, they can be transferred to the entity on the N-side.
لماذا ننقل خصائص علاقة 1:N إلى جهة N؟ لأن كل كيان في جهة N يشارك في علاقة واحدة فقط مع جهة 1، وبالتالي فإن قيمة الخاصية تعتمد كلياً على كيان جهة N.
أما في M:N، فالقيمة تعتمد على 'التركيبة' (Combination) من كلا الكيانين، لذا يجب أن تبقى على العلاقة.
Why transfer 1:N relationship attributes to the N-side? Because each entity on the N-side participates in exactly one relationship instance with the 1-side, making the attribute functionally dependent on the N-side entity alone.
In M:N, the attribute depends on the specific combination of both entities, so it must stay on the relationship.
لماذا لا يمكننا نقل خاصية 'عدد الساعات' من علاقة M:N إلى أحد الكيانين؟ Why can't we move the 'Hours' attribute from an M:N relationship to one of the participating entities?
لأن الموظف الواحد قد يعمل على عدة مشاريع بساعات مختلفة، والمشروع الواحد يضم عدة موظفين بساعات مختلفة. الساعات تعتمد على (الموظف والمشروع) معاً.
Because one employee works on many projects with different hours, and one project has many employees with different hours. The hours depend on the specific (Employee, Project) pair.
4 مخططات الفئات في UML
4 UML Class Diagrams
طريقة بديلة لتمثيل قواعد البيانات تُستخدم في هندسة البرمجيات، حيث تُمثل الكيانات كـ 'فئات' (Classes) والعلاقات كـ 'ارتباطات' (Associations).
An alternative notation used in software engineering where entities are 'Classes' and relationships are 'Associations'.
في UML، تُرسم الفئة كمربع مقسم لثلاثة أجزاء: الاسم، الخصائص، والعمليات (Operations - لا تُستخدم في ER الأساسي).
العلاقات تُسمى Associations وتُرسم كخطوط. التعددية (Multiplicities) تُكتب بصيغة min..max، ولكن توضع على الجانب المعاكس مقارنة بـ ER. الرمز * يعني N (بدون حد أقصى).
التجميع (Aggregation) هو علاقة بين كائن وأجزائه ويُرسم بمعين صغير.
In UML, a class is a box with 3 sections: Name, Attributes, and Operations (not in basic ER).
Relationships are 'Associations' drawn as lines. Multiplicities are written as min..max, but placed on the opposite end compared to ER notation. An asterisk (*) means no maximum limit.
Aggregation represents a whole-part relationship, drawn with a small diamond.
الفرق الجوهري في وضع التعددية ينبع من طريقة التفكير:
في ER، نحن ننظر إلى الكيان ونسأل 'كم مرة يشارك؟' فنضع الرقم بجانبه.
في UML، نحن نقف في الفئة وننظر عبر الارتباط (Navigation) لنسأل 'كم كائناً هناك يمكنني الوصول إليه؟' فنضع الرقم في الطرف الآخر.
The fundamental difference in multiplicity placement stems from perspective:
ER asks 'how many times does this entity participate?' and places the number next to it.
UML uses a navigation perspective, asking 'if I am at this class, how many instances of the other class can I navigate to?' placing the number at the target end.
| ER (min, max) | UML Multiplicity | |
|---|---|---|
| مكان وضع الأرقامPlacement of numbers | بجوار الكيان المعنيNext to the entity itself | على الطرف المعاكس للارتباطOn the opposite end of the association |
| صيغة الكتابةNotation Format | (min, max)(min, max) | min..maxmin..max |
| رمز اللانهايةInfinity Symbol | N أو MN or M | * (نجمة)* (Asterisk) |
إذا كان الموظف يعمل في قسم واحد، أين نضع '1..1' في مخطط UML؟ If an employee works in exactly one department, where do we place '1..1' in a UML diagram?
نضعها بجوار فئة 'القسم' (DEPARTMENT)، أي على الطرف المعاكس لفئة الموظف.
Next to the DEPARTMENT class, i.e., on the opposite end from the EMPLOYEE class.
5 العلاقات ذات الدرجات العليا (n-ary)
5 Relationships of Higher Degree
علاقات تربط ثلاثة كيانات أو أكثر في نفس الوقت (مثل المورد يورد قطعة لمشروع)، ولا يمكن دائماً تفكيكها لعلاقات ثنائية.
Relationships connecting three or more entities simultaneously (e.g., Supplier supplies Part to Project), which cannot always be decomposed into binary relationships.
درجة العلاقة هي عدد الكيانات المشاركة فيها. الدرجة 2 ثنائية، 3 ثلاثية (Ternary)، و n تسمى n-ary.
بشكل عام، العلاقة الثلاثية لا تكافئ ثلاث علاقات ثنائية، لأنها تمثل معلومة مختلفة (التركيبة المحددة للثلاثة معاً).
تحديد القيود (min, max) في هذه العلاقات أصعب، حيث يشير الرقم 1 إلى أن الكيان يشارك في مثيل علاقة واحد فقط لتركيبة معينة من الكيانات الأخرى.
The degree is the number of participating entities. Degree 2 is binary, 3 is ternary, n is n-ary.
In general, an n-ary relationship is not equivalent to n binary relationships because it represents different information (the specific combination of all entities).
Constraints are harder to specify; a '1' indicates an entity participates in at most one instance for a particular combination of the other entities.
متى نستخدم علاقة ثلاثية بدلاً من ثنائية؟ إذا كانت الحقيقة التي نريد تخزينها تتطلب الكيانات الثلاثة معاً لتكون صحيحة.
مثلاً، المورد S يورد القطعة P، والمشروع J يستخدم القطعة P، لا يعني بالضرورة أن المورد S يورد القطعة P للمشروع J تحديداً. العلاقة الثلاثية فقط هي التي تؤكد هذه الحقيقة المجمعة.
When to use ternary over binary? When the fact being recorded requires all three entities simultaneously.
For example, knowing Supplier S supplies Part P, and Project J uses Part P, does NOT guarantee that Supplier S supplies Part P *specifically to* Project J. Only a ternary relationship captures this combined semantic truth.
هل يمكن تحويل علاقة ثلاثية إلى كيان ضعيف؟ Can a ternary relationship be converted into a weak entity?
نعم، في بعض الحالات يمكن تمثيلها ككيان ضعيف يمتلك علاقات تعريف متعددة (Multiple identifying relationships) مع الكيانات المالكة.
Yes, in some cases it can be represented as a weak entity type if the data model allows multiple identifying relationships (multiple owner entity types).
6 الفئات الفرعية والعليا والوراثة (EER)
6 Subclasses, Superclasses, and Inheritance
الفئة العليا (مثل الموظف) تتفرع لفئات فرعية (مثل مهندس، سكرتير) ترث كل خصائصها وعلاقاتها، وتسمى علاقة IS-A.
A superclass (e.g., Employee) branches into subclasses (e.g., Engineer, Secretary) that inherit all its attributes and relationships. Known as an IS-A relationship.
نموذج EER يوسع ER لدعم التجريد.
الفئة الفرعية (Subclass): مجموعة فرعية من كيانات الفئة العليا (Superclass) لها خصائص مميزة. العلاقة بينهما تسمى IS-A (السكرتير 'هو' موظف).
الوراثة (Inheritance): أي كيان في الفئة الفرعية يرث تلقائياً جميع الخصائص (Attributes) والعلاقات (Relationships) الخاصة بالفئة العليا، بالإضافة إلى خصائصه المحلية (Local attributes).
The EER model extends ER to support abstraction.
Subclass: A meaningful subgroup of entities from a Superclass. The relationship is called IS-A (a SECRETARY IS-A EMPLOYEE).
Inheritance: An entity in a subclass automatically inherits all attributes and relationships of the superclass, in addition to its own specific (local) attributes.
نقطة حاسمة: الكيان في الفئة الفرعية يمثل نفس الكيان في العالم الحقيقي الموجود في الفئة العليا، ولكن بدور محدد.
لا يمكن لكيان أن يوجد في الفئة الفرعية دون أن يكون موجوداً في الفئة العليا. يمكن للكيان الواحد أن ينتمي لعدة فئات فرعية في نفس الوقت (مثل موظف براتب وهو أيضاً مهندس).
Crucial point: An entity in a subclass represents the same real-world entity as in the superclass, just in a specific role.
An entity cannot exist in the database merely by being a member of a subclass; it must also be a member of the superclass. One entity can belong to multiple subclasses simultaneously (e.g., a SALARIED_EMPLOYEE who is also an ENGINEER).
هل يجب أن ينتمي كل موظف (في الفئة العليا) إلى فئة فرعية واحدة على الأقل؟ Must every employee (in the superclass) belong to at least one subclass?
ليس بالضرورة. يمكن أن يكون هناك كيان في الفئة العليا لا ينتمي لأي فئة فرعية، ما لم يُنص على قيد يفرض ذلك (Total Specialization).
Not necessarily. An entity in a superclass does not have to be a member of any subclass, unless a specific constraint (Total Specialization) is defined.
7 التخصيص والتعميم
7 Specialization and Generalization
التخصيص هو تقسيم فئة عليا إلى فئات فرعية (من أعلى لأسفل)، والتعميم هو تجميع فئات مشتركة في فئة عليا (من أسفل لأعلى).
Specialization is splitting a superclass into subclasses (top-down). Generalization is grouping common classes into a superclass (bottom-up).
التخصيص (Specialization): عملية تعريف مجموعة من الفئات الفرعية بناءً على خصائص مميزة (مثل تقسيم الموظفين حسب نوع الوظيفة). تُرسم بخطوط متصلة بدائرة تحتوي رمز المجموعة الفرعية.
التعميم (Generalization): العملية العكسية؛ تجميع عدة فئات تشترك في خصائص معينة لتكوين فئة عليا (مثل تجميع 'سيارة' و'شاحنة' في فئة 'مركبة').
Specialization: The process of defining a set of subclasses of a superclass based on distinguishing characteristics (e.g., splitting EMPLOYEE by job type).
Generalization: The reverse process; several classes with common features are generalized into a superclass (e.g., CAR and TRUCK generalized into VEHICLE).
من الناحية الهيكلية (في مخطط EER)، النتيجة النهائية للتخصيص والتعميم تبدو متطابقة (فئة عليا متصلة بفئات فرعية).
الاختلاف يكمن فقط في عملية التصميم (Design Process): هل بدأنا بالعام ثم خصصنا (Top-down)، أم بدأنا بالخاص ثم عممنا (Bottom-up)؟
لذلك، لا نستخدم أسهماً لتمييزهما في المخطط لأن النتيجة الهيكلية واحدة.
Structurally (in the EER diagram), the end result of both specialization and generalization looks identical (a superclass connected to subclasses).
The difference lies purely in the design process: did we start general and go specific (Top-down), or start specific and abstract up (Bottom-up)?
Therefore, we typically do not use directional arrows to distinguish them, as the final schema is the same.
| Specialization (التخصيص) | Generalization (التعميم) | |
|---|---|---|
| اتجاه التصميمDesign Direction | من أعلى إلى أسفل (Top-down)Top-down | من أسفل إلى أعلى (Bottom-up)Bottom-up |
| نقطة البدايةStarting Point | فئة عليا واحدة يتم تقسيمهاSingle superclass being split | عدة فئات يتم تجميعهاMultiple classes being grouped |
| النتيجة في المخططDiagram Result | متطابقة (فئة عليا وفرعية)Identical (Superclass/Subclass) | متطابقة (فئة عليا وفرعية)Identical (Superclass/Subclass) |
لماذا لا نستخدم أسهماً في مخطط EER للتفريق بين التخصيص والتعميم؟ Why don't we use arrows in EER diagrams to distinguish between specialization and generalization?
لأن النتيجة النهائية للمخطط متطابقة، واستخدام الأسهم قد يكون غير واضح أو شخصي يعتمد على طريقة تفكير المصمم.
Because the final schema structure is identical, and using arrows is often unclear or subjective regarding which process the designer actually used.