نموذج الكيان والعلاقة - الجزء الأول
مقدمة في تصميم قواعد البيانات باستخدام نموذج الكيان والعلاقة (ER Model)، بما في ذلك الكيانات، السمات، العلاقات، والكيانات الضعيفة.
Entity-Relationship Model-1
Introduction to database design using the Entity-Relationship (ER) Model, including entities, attributes, relationships, and weak entities.
أهداف التعلم
- شرح نموذج الكيان والعلاقة (ER Model) ومفاهيمه الأساسية.
- التمييز بين أنواع السمات المختلفة (بسيطة، مركبة، متعددة القيم).
- تصميم مخططات ER المبدئية وتحسينها باستخدام العلاقات.
- تحديد الكيانات الضعيفة وفهم كيفية ارتباطها بالكيانات المالكة.
- Explain the Entity-Relationship (ER) model and its core concepts.
- Differentiate between various types of attributes (simple, composite, multi-valued).
- Design initial ER schemas and refine them by introducing relationships.
- Identify weak entity types and understand how they relate to owner entities.
1 عملية تصميم قاعدة البيانات
1 Database Design Process
عملية تحويل متطلبات العالم الحقيقي إلى مخطط قاعدة بيانات منظم، مع التركيز على التصميم المفاهيمي.
The process of translating real-world requirements into a structured database schema, focusing on Conceptual Design.
تتكون عملية التصميم من نشاطين رئيسيين: تصميم مخطط قاعدة البيانات وتصميم برامج التطبيقات.
يركز هذا المفهوم على التصميم المفاهيمي (Conceptual Design)، والذي يأتي بعد جمع المتطلبات وتحليلها. في هذه المرحلة، يتم استخدام نماذج بيانات عالية المستوى مثل نموذج ER لإنشاء مخطط مفاهيمي مستقل عن نظام إدارة قواعد البيانات (DBMS) المحدد.
The design process consists of two main activities: Database schema design and Application programs design.
This concept focuses on Conceptual Design, which follows requirements collection and analysis. In this phase, high-level data models like the ER model are used to create a conceptual schema that is independent of any specific DBMS.
لماذا نفصل التصميم المفاهيمي عن التصميم المنطقي والمادي؟ يتيح ذلك للمصممين التركيز على هيكل البيانات ومعناها دون التورط في تفاصيل التنفيذ التقنية.
هذا المخطط المفاهيمي يسهل التواصل مع أصحاب المصلحة غير التقنيين قبل تحويله إلى جداول فعلية (تصميم منطقي) وتحديد هياكل التخزين (تصميم مادي).
Why separate conceptual design from logical and physical design? It allows designers to focus on the data structure and meaning without getting bogged down by technical implementation details.
This conceptual schema facilitates communication with non-technical stakeholders before it is mapped to actual tables (logical design) and storage structures (physical design).
ماذا يحدث إذا تخطينا مرحلة التصميم المفاهيمي وانتقلنا مباشرة إلى التصميم المادي؟ What happens if we skip the conceptual design phase and jump straight to physical design?
سيؤدي ذلك إلى قاعدة بيانات غير مرنة، صعبة الفهم، ومليئة بالأخطاء الهيكلية لأن متطلبات العمل لم تُترجم بشكل صحيح إلى نموذج بيانات واضح قبل التنفيذ التقني.
It would lead to an inflexible, hard-to-understand database full of structural errors because business requirements weren't properly translated into a clear data model before technical implementation.
2 الكيانات والسمات
2 Entities and Attributes
الكيان هو شيء في العالم الحقيقي (مثل موظف)، والسمات هي خصائصه (مثل الاسم والعمر).
An entity is a real-world object (like an Employee), and attributes are its properties (like Name and Age).
الكيانات (Entities): هي كائنات أو أشياء محددة في العالم المصغر (mini-world) يتم تمثيلها في قاعدة البيانات (مثل: الموظف جون سميث، قسم الأبحاث).
السمات (Attributes): هي الخصائص المستخدمة لوصف الكيان. كل سمة لها مجموعة قيم (Value Set) أو نوع بيانات مرتبط بها (مثل: عدد صحيح، نص).
أنواع السمات تشمل:
- بسيطة (Simple/Atomic): قيمة واحدة غير قابلة للتجزئة (مثل: رقم الضمان الاجتماعي SSN).
- مركبة (Composite): تتكون من عدة مكونات (مثل: العنوان يتكون من مدينة، شارع، رقم المبنى).
- متعددة القيم (Multi-valued): يمكن أن يكون للكيان قيم متعددة لهذه السمة (مثل: ألوان السيارة، الشهادات السابقة)، ويُشار إليها بـ {السمة}.
Entities: Specific objects or things in the mini-world represented in the database (e.g., EMPLOYEE John Smith, Research DEPARTMENT).
Attributes: Properties used to describe an entity. Each attribute has a value set (data type) associated with it (e.g., integer, string).
Types of attributes include:
- Simple (Atomic): A single, indivisible value (e.g., SSN).
- Composite (Compound): Composed of several components (e.g., Address = City, Street, Building Number).
- Multi-valued: An entity may have multiple values for this attribute (e.g., Car Colors, Previous Degrees), denoted as {Attribute}.
السمات المركبة والمتعددة القيم يمكن أن تتداخل لأي عدد من المستويات. على سبيل المثال، يمكن أن تكون السمة {الشهادات السابقة} متعددة القيم، وكل شهادة بحد ذاتها سمة مركبة تتكون من (الكلية، السنة، الدرجة).
هذا التعقيد الهرمي يمثل تحدياً عند تحويل نموذج ER إلى جداول علائقية (حيث تتطلب قواعد البيانات العلائقية سمات ذرية).
Composite and multi-valued attributes can be nested to any number of levels. For example, {PreviousDegrees} can be a multi-valued attribute, where each degree is a composite attribute consisting of (College, Year, Degree).
This hierarchical complexity presents a challenge when mapping the ER model to relational tables (which require atomic attributes).
| Simple Attribute | Composite Attribute | Multi-valued Attribute | |
|---|---|---|---|
| قابلية التجزئةDivisibility | غير قابل للتجزئة (ذري).Indivisible (atomic). | قابل للتجزئة إلى مكونات فرعية.Divisible into subcomponents. | غير قابل للتجزئة بالضرورة، لكنه يحمل قيماً متعددة.Not necessarily divisible, but holds multiple values. |
| أمثلةExamples | العمر، الجنس، رقم الضمان الاجتماعي.Age, Sex, SSN. | العنوان (مدينة، شارع)، الاسم (أول، أخير).Address (City, Street), Name (First, Last). | ألوان السيارة، الشهادات السابقة.Car Colors, Previous Degrees. |
متى يجب أن نعتبر 'العنوان' سمة مركبة بدلاً من سمة بسيطة؟ When should we consider 'Address' as a composite attribute rather than a simple attribute?
إذا كان التطبيق يحتاج إلى الاستعلام عن مكونات العنوان بشكل منفصل (مثل البحث عن جميع الموظفين في 'مدينة' معينة)، فيجب أن يكون مركباً. إذا كان يُعامل كنص واحد فقط للطباعة، فيمكن أن يكون بسيطاً.
If the application needs to query the address components separately (e.g., finding all employees in a specific 'City'), it should be composite. If it's only treated as a single string for printing, it can be simple.
3 أنواع الكيانات، مجموعات الكيانات، والمفاتيح
3 Entity Types, Sets, and Keys
نوع الكيان هو القالب (مثل 'موظف')، ومجموعة الكيانات هي البيانات الفعلية. السمة المفتاحية هي المعرف الفريد.
Entity type is the template (e.g., 'Employee'), entity set is the actual data. A key attribute is the unique identifier.
نوع الكيان (Entity Type): يجمع الكيانات التي لها نفس السمات الأساسية (مثل: نوع الكيان EMPLOYEE). يُرسم كمستطيل في مخطط ER.
مجموعة الكيانات (Entity Set): هي مجموعة الكيانات الفردية المخزنة في قاعدة البيانات في وقت معين (تمثل الحالة الحالية).
السمة المفتاحية (Key Attribute): سمة يجب أن يكون لها قيمة فريدة (متميزة) لكل كيان في مجموعة الكيانات (مثل: SSN للموظف). يمكن أن يكون المفتاح مركباً (مثل: رقم لوحة السيارة يتكون من الرقم والولاية)، ويمكن أن يكون لنوع الكيان أكثر من مفتاح واحد. تُوضع خط تحت السمة المفتاحية في مخططات ER.
Entity Type: Groups entities with the same basic attributes (e.g., EMPLOYEE). Displayed as a rectangular box in ER diagrams.
Entity Set: The collection of individual entities stored in the database at a specific time (represents the current state).
Key Attribute: An attribute for which each entity must have a unique (distinct) value (e.g., SSN). A key can be composite (e.g., LicensePlate = Number + State), and an entity type may have more than one key. Key attributes are underlined in ER diagrams.
التمييز بين نوع الكيان ومجموعة الكيانات يشبه التمييز بين الفئة (Class) والكائن (Object) في البرمجة كائنية التوجه.
نوع الكيان ثابت (المخطط/Schema)، بينما مجموعة الكيانات تتغير بمرور الوقت مع إضافة أو حذف الكيانات (الحالة/State).
The distinction between entity type and entity set is similar to the distinction between a Class and an Object in OOP.
The entity type is static (the schema), while the entity set changes over time as entities are created and deleted (the state).
| Entity Type | Entity Set | |
|---|---|---|
| التعريفDefinition | وصف المخطط (Schema) والسمات المشتركة.Schema description and shared attributes. | البيانات الفعلية المخزنة في لحظة معينة.Actual data stored at a specific moment. |
| التغير بمرور الوقتChange over time | ثابت (لا يتغير إلا بتعديل التصميم).Static (changes only if design is altered). | متغير (يتغير مع إضافة/حذف الكيانات).Dynamic (changes as entities are added/deleted). |
هل يمكن أن يكون لنوع الكيان أكثر من سمة مفتاحية واحدة؟ أعط مثالاً. Can an entity type have more than one key attribute? Give an example.
نعم، يمكن أن يكون للكيان مفاتيح متعددة. مثال: كيان 'السيارة' يمكن أن يكون له مفتاح 'رقم تعريف المركبة (VIN)' ومفتاح آخر مركب 'رقم اللوحة (الرقم، الولاية)'.
Yes, an entity type can have multiple keys. Example: A 'CAR' entity can have a 'Vehicle Identification Number (VIN)' as one key, and a composite 'License Plate (Number, State)' as another key.
4 العلاقات، أنواع العلاقات، ومجموعات العلاقات
4 Relationships, Relationship Types, and Sets
العلاقة تربط بين كيانين أو أكثر. نوع العلاقة هو المخطط (يُرسم كمعين)، ومجموعة العلاقات هي الروابط الفعلية.
A relationship connects two or more entities. Relationship type is the schema (diamond shape), relationship set is the actual links.
العلاقة (Relationship): تربط بين كيانين متميزين أو أكثر بمعنى محدد (مثل: الموظف جون يعمل في مشروع X).
نوع العلاقة (Relationship Type): هو وصف المخطط للعلاقة، ويحدد اسم العلاقة وأنواع الكيانات المشاركة. يُعرض في مخطط ER كصندوق على شكل معين (Diamond) متصل بخطوط مستقيمة بأنواع الكيانات المشاركة.
مجموعة العلاقات (Relationship Set): هي المجموعة الحالية من حالات العلاقة (Relationship instances) الممثلة في قاعدة البيانات.
درجة العلاقة (Degree): هي عدد أنواع الكيانات المشاركة في العلاقة. العلاقة بين كيانين تسمى علاقة ثنائية (Binary).
Relationship: Relates two or more distinct entities with a specific meaning (e.g., EMPLOYEE John works on PROJECT X).
Relationship Type: The schema description of a relationship, identifying its name and participating entity types. Displayed in ER diagrams as a diamond-shaped box connected by straight lines to participating entity types.
Relationship Set: The current set of relationship instances represented in the database.
Degree of a relationship: The number of participating entity types. A relationship between two entities is a binary relationship.
أثناء تحسين التصميم المبدئي (Refining the initial design)، يتم تحويل السمات التي تشير إلى كيانات أخرى إلى علاقات.
على سبيل المثال، بدلاً من جعل 'القسم' سمة داخل كيان 'الموظف'، نقوم بإنشاء علاقة WORKS_FOR بين كيان الموظف وكيان القسم. هذا يمنع تكرار البيانات ويحافظ على سلامة المراجع.
During the refinement of the initial design, attributes that refer to other entities are converted into relationships.
For example, instead of having 'Department' as an attribute within the 'EMPLOYEE' entity, we create a WORKS_FOR relationship between EMPLOYEE and DEPARTMENT. This prevents data redundancy and maintains referential integrity.
لماذا نفضل استخدام العلاقات بدلاً من السمات للإشارة إلى كيانات أخرى؟ Why do we prefer using relationships instead of attributes to refer to other entities?
لأن استخدام العلاقات يوضح الروابط الهيكلية بين الكيانات، يمنع تكرار البيانات، ويسمح بوضع قيود هيكلية (مثل التعددية) على العلاقة، مما يضمن سلامة البيانات.
Because using relationships clarifies the structural links between entities, prevents data redundancy, and allows us to enforce structural constraints (like cardinality) on the relationship, ensuring data integrity.
5 العلاقات العودية (الذاتية)
5 Recursive Relationship Type
علاقة يشارك فيها نفس نوع الكيان مرتين بأدوار مختلفة (مثل موظف يشرف على موظف آخر).
A relationship type where the same entity type participates twice in two distinct roles (e.g., an employee supervising another employee).
العلاقة العودية (Recursive Relationship): هي نوع علاقة يشارك فيها نفس نوع الكيان مرتين في دورين متميزين (distinct roles).
مثال كلاسيكي هو علاقة الإشراف (SUPERVISION) بين الموظفين. يشارك كيان EMPLOYEE مرتين:
- دور المشرف (Supervisor / Boss).
- دور الخاضع للإشراف (Supervisee / Subordinate).
في هذه الحالة، من الضروري التمييز بين الأدوار في حالة العلاقة (Relationship instance) لمعرفة من يشرف على من. في مخطط ER، تُرسم خطوط العلاقة من المعين عائدة إلى نفس مستطيل الكيان، مع كتابة أسماء الأدوار على الخطوط.
Recursive Relationship Type: A relationship type where the same entity type participates twice in two distinct roles.
A classic example is the SUPERVISION relationship among employees. The EMPLOYEE entity participates twice:
- Supervisor (or boss) role.
- Supervisee (or subordinate) role.
In this case, it is essential to distinguish the roles in a relationship instance to know who supervises whom. In ER diagrams, relationship lines are drawn from the diamond back to the same entity rectangle, with role names labeled on the lines.
بدون تحديد أسماء الأدوار (Role names) في العلاقات العودية، سيكون المخطط غامضاً ولن نتمكن من تحديد اتجاه العلاقة.
في قواعد البيانات العلائقية، يتم تنفيذ ذلك عادةً باستخدام مفتاح أجنبي (Foreign Key) داخل الجدول يشير إلى المفتاح الأساسي (Primary Key) لنفس الجدول (مثل عمود Supervisor_SSN في جدول EMPLOYEE).
Without specifying role names in recursive relationships, the schema would be ambiguous, and we couldn't determine the direction of the relationship.
In relational databases, this is typically implemented using a Foreign Key within the table that references the Primary Key of the same table (e.g., a Supervisor_SSN column in the EMPLOYEE table).
هل يمكن أن تكون العلاقة العودية من درجة أعلى من 2؟ Can a recursive relationship have a degree higher than 2?
نظرياً نعم، يمكن أن يشارك نفس الكيان 3 مرات بأدوار مختلفة (علاقة ثلاثية عودية)، لكنها نادرة جداً في الممارسة العملية. العلاقات العودية الثنائية هي الأكثر شيوعاً.
Theoretically yes, the same entity could participate 3 times in different roles (a ternary recursive relationship), but it is extremely rare in practice. Binary recursive relationships are the most common.
6 أنواع الكيانات الضعيفة
6 Weak Entity Types
كيان لا يملك مفتاحاً خاصاً به، ويعتمد في تعريفه على كيان آخر (المالك) وعلاقة تعريف.
An entity type that does not have a key attribute of its own and depends on another entity (the owner) for identification.
الكيان الضعيف (Weak Entity Type): هو نوع كيان لا يحتوي على سمة مفتاحية خاصة به. لا يمكن تحديد كياناته الفردية إلا من خلال علاقتها بكيانات أخرى.
يجب أن يشارك الكيان الضعيف في علاقة تعريف (Identifying Relationship) مع نوع كيان مالك (Owner / Identifying Entity Type).
يتم تحديد الكيانات الفردية الضعيفة من خلال مزيج من:
- الكيان المالك الذي ترتبط به.
- مفتاح جزئي (Partial Key) للكيان الضعيف.
مثال: كيان DEPENDENT (المُعال) هو كيان ضعيف. يتم تحديده من خلال الموظف (المالك) الذي يعوله، بالإضافة إلى الاسم الأول للمُعال (المفتاح الجزئي). في مخطط ER، يُرسم الكيان الضعيف بمستطيل مزدوج الخطوط، وعلاقة التعريف بمعين مزدوج الخطوط، والمفتاح الجزئي بخط متقطع تحته.
Weak Entity Type: An entity type that does not have a key attribute of its own. Its individual entities cannot be uniquely identified by their attributes alone.
A weak entity must participate in an identifying relationship type with an owner (or identifying) entity type.
Individual entities are identified by the combination of:
- The specific owner entity they are related to.
- A partial key of the weak entity type.
Example: The DEPENDENT entity is a weak entity. It is identified by the EMPLOYEE (owner) it is related to, plus the dependent's first name (partial key). In ER diagrams, a weak entity is drawn with a double-lined rectangle, the identifying relationship with a double-lined diamond, and the partial key with a dashed underline.
الكيانات الضعيفة تجسد مفهوم الاعتمادية الوجودية (Existence Dependency). إذا تم حذف الكيان المالك (مثل الموظف)، يجب أن تُحذف جميع الكيانات الضعيفة المرتبطة به (مثل المُعالين) تلقائياً (Cascade Delete).
هذا المفهوم حاسم عند تصميم قواعد البيانات لضمان عدم وجود سجلات يتيمة (Orphan Records).
Weak entities embody the concept of existence dependency. If the owner entity (e.g., EMPLOYEE) is deleted, all its associated weak entities (e.g., DEPENDENTs) must be automatically deleted (Cascade Delete).
This concept is crucial in database design to ensure no orphan records exist.
لماذا لا نجعل 'الاسم الأول للمُعال' مفتاحاً أساسياً عادياً بدلاً من مفتاح جزئي؟ Why don't we just make the 'Dependent First Name' a regular primary key instead of a partial key?
لأن الاسم الأول وحده لا يضمن التفرد في قاعدة البيانات بأكملها (قد يكون لموظفين مختلفين أبناء بنفس الاسم 'علي'). التفرد يتحقق فقط عند دمج اسم المُعال مع معرف الموظف المالك.
Because the first name alone does not guarantee uniqueness across the entire database (two different employees might both have a child named 'Ali'). Uniqueness is only achieved when combining the dependent's name with the owner employee's ID.