التحليل: نمذجة البيانات المفاهيمية
تغطي هذه الوحدة عملية نمذجة البيانات المفاهيمية، وجمع المعلومات، ونمذجة الكيان والعلاقة (E-R)، وقواعد الأعمال، ومخططات الفئات (Class Diagrams) في تحليل وتصميم النظم.
Analysis: Conceptual Data Modeling
This module covers the conceptual data modeling process, gathering information, Entity-Relationship (E-R) modeling, business rules, and Class Diagrams in system analysis and design.
أهداف التعلم
- فهم نمذجة البيانات المفاهيمية للنظام.
- التعرف على نموذج الكيان والعلاقة وفهمه.
- تحديد قواعد الأعمال في نموذج البيانات المفاهيمي.
- Understand the conceptual data modeling of a system.
- Recognize and understand entity-relationship model.
- Define business rules in conceptual data model.
1 عملية نمذجة البيانات المفاهيمية
1 Conceptual Data Modeling Process
هي تمثيل تفصيلي لبيانات المؤسسة، مستقل عن أي نظام إدارة قواعد بيانات (DBMS)، يهدف إلى التقاط الهيكل العام للبيانات.
A detailed representation of organizational data that captures the overall structure independent of any DBMS.
يمكن إجراء نمذجة البيانات المفاهيمية بالتوازي مع خطوات تحليل المتطلبات الأخرى.
في المشاريع الكبيرة، يعمل جزء من الفريق على نمذجة البيانات بينما يعمل الجزء الآخر على نمذجة العمليات.
يتم تنسيق العمل من خلال قاموس المشروع أو المستودع.
المخرج الأساسي لهذه العملية في مرحلة التحليل هو مخطط الكيان والعلاقة (E-R Diagram).
The conceptual data model can be done in parallel with other requirements analysis steps.
In large projects, teams split the work between data modeling and process/logic modeling, coordinating through a project dictionary or repository.
The primary deliverable of this process during the analysis phase is an E-R diagram.
لماذا نبدأ بنموذج مفاهيمي؟
إذا كان النظام سيحل محل نظام قديم، فإن النموذج المفاهيمي ضروري لفهم متطلبات البيانات بوضوح ولتسهيل تحويل الملفات أو قواعد البيانات الحالية إلى قاعدة بيانات النظام الجديد.
يتطور هذا النموذج عبر دورة حياة تطوير النظم (SDLC) من التخطيط إلى الصيانة.
Why start with a conceptual model?
If a system is being replaced, it is crucial for understanding data requirements and converting current files/databases into the new system's database.
The model evolves throughout the SDLC, starting from E-R/Class diagramming in Planning, becoming specific in Analysis, translating to physical storage decisions in Design, and evolving during Maintenance.
لماذا يجب أن يكون نموذج البيانات المفاهيمي مستقلاً عن نظام إدارة قواعد البيانات (DBMS)؟ Why should a conceptual data model be independent of the DBMS?
لضمان التركيز على متطلبات العمل الحقيقية وهيكل البيانات بدلاً من القيود التقنية، مما يجعله قابلاً للتكيف مع أي تقنية لاحقاً.
To ensure the focus remains on actual business requirements and data structure rather than technical constraints, making it adaptable to any technology later.
2 مناهج جمع المعلومات لنمذجة البيانات
2 Gathering Information Approaches
يمكن جمع متطلبات البيانات من خلال نهجين: من أعلى إلى أسفل (فهم طبيعة العمل) ومن أسفل إلى أعلى (مراجعة المستندات والنماذج).
Data requirements can be gathered through two approaches: Top-down (understanding business nature) and Bottom-up (reviewing specific documents).
يجب أن يجيب نموذج البيانات على: ماذا تفعل المؤسسة؟ وما هي القواعد التي تحكم العمل؟ ولا ينبغي أن يجيب على: كيف أو متى تتم معالجة البيانات؟
النهج من أعلى إلى أسفل (Top-down): يستمد قواعد الأعمال من الفهم العميق لطبيعة العمل (مثل المقابلات وجلسات JAD).
النهج من أسفل إلى أعلى (Bottom-up): يستمد القواعد من مراجعة مستندات عمل محددة مثل شاشات الكمبيوتر، التقارير، والنماذج.
The data model should answer: What the organization does? and What rules govern performing the work? It should NOT answer how or when data is processed.
Top-down approach: Derives business rules from an intimate understanding of the nature of the business (e.g., via JAD sessions, interviews).
Bottom-up approach: Derives business rules from reviewing specific business documents such as computer displays, reports, and business forms.
يعد الجمع بين النهجين أمراً مثالياً.
النهج من أعلى إلى أسفل يوفر الرؤية الشاملة والأساس لنماذج البيانات الجاهزة، بينما يضمن النهج من أسفل إلى أعلى عدم إغفال أي حقل بيانات دقيق مستخدم حالياً في العمليات اليومية (والتي تظهر كتدفقات بيانات في DFDs).
Combining both approaches is ideal.
Top-down provides the holistic vision and basis for purchased data models, while bottom-up ensures no granular data field currently used in daily operations (appearing as data flows on DFDs) is missed.
| النهج من أعلى إلى أسفلTop-down Approach | النهج من أسفل إلى أعلىBottom-up Approach | |
|---|---|---|
| مصدر استنباط القواعدSource of Deriving Rules | الفهم العميق لطبيعة العملIntimate understanding of business nature | مراجعة مستندات عمل محددة (تقارير، نماذج)Reviewing specific business documents |
| الارتباط بنماذج أخرىConnection to other models | أساس لنماذج البيانات الجاهزةBasis for purchased data models | تظهر كمصادر لتدفقات البيانات في DFDsAppear as data flows on DFDs |
إذا كنت تصمم نظاماً لشركة ناشئة ليس لديها نماذج أو تقارير سابقة، أي نهج ستعتمد عليه بشكل أساسي؟ If you are designing a system for a startup with no existing forms or reports, which approach would you primarily rely on?
النهج من أعلى إلى أسفل (Top-down)، لأنه يعتمد على فهم طبيعة العمل والمقابلات بدلاً من المستندات الموجودة مسبقاً.
The Top-down approach, because it relies on understanding the business nature and interviews rather than pre-existing documents.
3 نمذجة الكيان والعلاقة: الكيانات والسمات
3 E-R Modeling: Entities and Attributes
الكيان هو شخص أو شيء أو حدث تهتم المؤسسة بجمع بيانات عنه، والسمة هي خاصية تصف هذا الكيان.
An entity is a person, object, or event the organization wants to maintain data about, and an attribute is a property describing it.
الكيان (Entity): له هويته الخاصة. نوع الكيان (Entity Type) هو مجموعة من الكيانات التي تشترك في الخصائص، بينما مثيل الكيان (Entity Instance) هو حدوث واحد. يجب تسمية الكيان باسم مفرد وموجز.
السمات (Attributes): خصائص الكيان.
المفتاح المرشح (Candidate Key): سمة تحدد كل مثيل بشكل فريد.
المعرف (Identifier): هو المفتاح المرشح الذي تم اختياره ليكون المعرف الأساسي.
أنواع السمات الأخرى تشمل: متعددة القيم، مركبة، مشتقة، مطلوبة، واختيارية.
Entity: Has its own identity. An Entity Type is a collection of entities sharing common properties, while an Entity Instance is a single occurrence. Entities should be named with singular, concise nouns.
Attributes: Properties of an entity.
Candidate Key: An attribute that uniquely identifies each instance.
Identifier: The candidate key selected to be the unique characteristic.
Other attribute types include: multivalued, composite, derived, required, and optional.
اختيار المعرف (Identifier) يتطلب الحذر؛ يجب ألا تتغير قيمته أبداً طوال دورة حياة مثيل الكيان، ويجب ألا يكون فارغاً (Null).
السمات المشتقة (Derived Attributes) لا تُخزن فعلياً في قاعدة البيانات بل تُحسب عند الحاجة (مثل العمر من تاريخ الميلاد) لتقليل تكرار البيانات وضمان التحديث التلقائي.
Selecting an Identifier requires care; its value must never change throughout the entity instance's lifecycle and must not be null.
Derived attributes are not physically stored but calculated on the fly (e.g., Age from Birth_Date) to reduce redundancy and ensure automatic updates.
لماذا نعتبر (الاسم والعنوان) معاً مفتاحاً مرشحاً ضعيفاً للموظف؟ Why is the combination of (Name and Address) considered a weak candidate key for an Employee?
لأنه من الممكن (وإن كان نادراً) أن يعيش شخصان بنفس الاسم في نفس العنوان، كما أن العنوان والاسم قد يتغيران بمرور الوقت، مما ينتهك شروط المعرف الجيد.
Because it is possible (though rare) for two people with the same name to live at the same address, and both name and address can change over time, violating the rules of a good identifier.
4 نمذجة الكيان والعلاقة: العلاقات والعددية (Cardinality)
4 E-R Modeling: Relationships and Cardinality
العلاقة هي ارتباط بين الكيانات، والعددية (Cardinality) تحدد الحد الأدنى والأقصى لعدد المثيلات المرتبطة.
A relationship is an association between entities, and cardinality defines the minimum and maximum number of associated instances.
العلاقة (Relationship): ارتباط بين مثيلات نوع كيان واحد أو أكثر. يجب تسميتها بعبارة فعلية (Verb phrase).
درجة العلاقة (Degree): عدد أنواع الكيانات المشاركة (أحادية Unary، ثنائية Binary، ثلاثية Ternary).
العددية (Cardinality): عدد مثيلات الكيان X التي يمكن أن ترتبط بكل مثيل من الكيان Y. تشمل الحد الأدنى (Minimum Cardinality) والحد الأقصى (Maximum Cardinality) مثل: واحد إلزامي (Mandatory One)، متعدد إلزامي (Mandatory Many)، واحد اختياري (Optional One)، متعدد اختياري (Optional Many).
Relationship: An association between instances of one or more entity types. It should be named with a verb phrase.
Degree: The number of entity types participating (Unary, Binary, Ternary).
Cardinality: The number of instances of entity X that can be associated with each instance of entity Y. It includes Minimum and Maximum cardinality (e.g., Mandatory One, Mandatory Many, Optional One, Optional Many).
تعتبر العلاقات الثلاثية (Ternary) معقدة وغالباً ما يتم حلها في التصميم المنطقي عن طريق إنشاء كيان وسيط (Associative Entity) يحول العلاقة الثلاثية إلى ثلاث علاقات ثنائية، مما يسهل تنفيذها في قواعد البيانات العلائقية.
Ternary relationships are complex and are often resolved during logical design by creating an Associative Entity, which converts the ternary relationship into three binary relationships, making it easier to implement in relational databases.
ماذا يعني أن يكون الحد الأدنى للعددية صفراً (Optional)؟ What does it mean when the minimum cardinality is zero (Optional)?
يعني أن مشاركة الكيان في العلاقة ليست إلزامية؛ يمكن أن يوجد مثيل للكيان دون أن يكون مرتبطاً بأي مثيل من الكيان الآخر.
It means participation in the relationship is not mandatory; an entity instance can exist without being associated with any instance of the other entity.
5 قواعد الأعمال والنطاقات
5 Business Rules and Domains
قواعد الأعمال هي مواصفات تحافظ على سلامة نموذج البيانات المنطقي وتمنع إدخال بيانات غير صالحة.
Business rules are specifications that preserve the integrity of the logical data model and prevent invalid data entry.
أنواع قواعد الأعمال تشمل:
- 1. سلامة الكيان (Entity integrity): يجب أن يكون المعرف الفريد غير فارغ (Not Null) لكل مثيل.
- 2. قيود السلامة المرجعية (Referential integrity): قواعد تتعلق بالعلاقات بين أنواع الكيانات.
- 3. النطاقات (Domains): قيود على القيم الصالحة للسمات (مثل: نوع البيانات، التنسيق، النطاق من 0-10000).
- 4. العمليات المحفزة (Triggering operations): قواعد تحمي صحة قيم السمات بناءً على أحداث معينة (مثل: رفض عملية سحب إذا كان المبلغ يتجاوز الرصيد).
Types of business rules include:
- 1. Entity integrity: A unique identifier that is not null for each instance.
- 2. Referential integrity constraints: Rules related to relationships between entity types.
- 3. Domains: Constraints on valid values for attributes (e.g., data type, format, range 0-10,000).
- 4. Triggering operations: Rules that protect the validity of attribute values based on events (e.g., reject a withdrawal if the amount exceeds the account balance).
تعتبر العمليات المحفزة (Triggers) ضرورية لتطبيق منطق العمل المعقد الذي لا يمكن التعبير عنه بمجرد قيود النطاق أو المفاتيح.
يتم تنفيذها عادةً على مستوى قاعدة البيانات لضمان عدم تجاوزها من قبل أي تطبيق واجهة مستخدم.
Triggering operations are essential for enforcing complex business logic that cannot be expressed merely by domain constraints or keys.
They are usually implemented at the database level to ensure they cannot be bypassed by any frontend application.
كيف يختلف النطاق (Domain) عن العملية المحفزة (Triggering Operation)؟ How does a Domain differ from a Triggering Operation?
النطاق يحدد القيم الثابتة المقبولة لسمة واحدة (مثل الأرقام فقط)، بينما العملية المحفزة تنفذ منطقاً ديناميكياً قد يتضمن سمات أو كيانات متعددة عند حدوث حدث معين.
A domain defines static acceptable values for a single attribute (e.g., numbers only), while a triggering operation executes dynamic logic potentially involving multiple attributes/entities when a specific event occurs.
6 مخططات الفئات: الكائنات، الفئات، والعمليات
6 Class Diagrams: Objects, Classes, and Operations
مخطط الفئة يوضح الهيكل الثابت للنظام الموجه للكائنات، حيث يجمع الكائنات ذات الخصائص والسلوكيات المتشابهة في فئات (Classes).
A class diagram shows the static structure of an object-oriented model, grouping objects with similar properties and behaviors into Classes.
الكائن (Object): له حالة (بيانات/سمات)، وسلوك (عمليات)، وهوية.
الفئة (Class): تجميع منطقي للكائنات المتشابهة. في UML، تُمثل الفئة بمستطيل مقسم لثلاثة أجزاء: اسم الفئة، السمات، والعمليات.
التغليف (Encapsulation): إخفاء تفاصيل التنفيذ الداخلي للكائن.
أنواع العمليات:
- 1. البناء (Constructor): لإنشاء مثيل جديد.
- 2. الاستعلام (Query): للوصول للحالة دون تغييرها.
- 3. التحديث (Update): لتغيير حالة الكائن.
- 4. نطاق الفئة (Class-scope): عملية تُطبق على الفئة ككل وليس على مثيل محدد.
Object: Has state (data), behavior, and identity.
Class: A logical grouping of similar objects. In UML, a class is a rectangle with three compartments: Name, Attributes, and Operations.
Encapsulation: Hiding internal implementation details.
Operation Types:
- 1. Constructor: creates a new instance.
- 2. Query: accesses state without altering it.
- 3. Update: alters the state.
- 4. Class-scope: applies to the class rather than an object instance.
التغليف هو جوهر البرمجة الموجهة للكائنات (OOP)؛ فهو يحمي حالة الكائن من التعديلات غير المقصودة ويجبر الأنظمة الخارجية على التفاعل مع الكائن فقط من خلال واجهته العامة (العمليات المحددة).
Encapsulation is the core of OOP; it protects the object's state from unintended modifications and forces external systems to interact with the object only through its public interface (defined operations).
متى نستخدم عملية بنطاق الفئة (Class-scope operation) بدلاً من عملية عادية؟ When do we use a Class-scope operation instead of a regular operation?
نستخدمها عندما نحتاج إلى إجراء لا يعتمد على حالة مثيل معين، مثل حساب إجمالي عدد الكائنات التي تم إنشاؤها من هذه الفئة.
We use it when we need an action that does not depend on the state of a specific instance, such as counting the total number of objects created from that class.
7 مخططات الفئات: الارتباطات والفئات الترابطية
7 Class Diagrams: Associations and Associative Classes
الارتباط (Association) هو علاقة مسماة بين الفئات، والتعددية (Multiplicity) تحدد عدد الكائنات المشاركة.
An Association is a named relationship between classes, and Multiplicity indicates how many objects participate.
الارتباط (Association): يظهر كخط صلب بين الفئات المشاركة.
دور الارتباط (Association role): نهاية الارتباط حيث يتصل بالفئة.
التعددية (Multiplicity): تعادل العددية (Cardinality) في E-R، وتحدد كم عدد الكائنات التي تشارك (مثل 0..1, 1..*).
الفئة الترابطية (Associative Class): تُستخدم عندما يكون للارتباط نفسه سمات أو عمليات خاصة به، أو عندما يشارك في علاقات مع فئات أخرى (مثل فئة 'التسجيل' بين الطالب والمقرر).
Association: Shown as a solid line between participating classes.
Association role: The end of an association where it connects to a class.
Multiplicity: Equivalent to Cardinality in E-R, indicating how many objects participate (e.g., 0..1, 1..*).
Associative Class: Used if an association itself has attributes/operations of its own or participates in relationships with other classes (e.g., a 'Registration' class between Student and Course).
الفئة الترابطية تحل مشكلة العلاقات من نوع (متعدد إلى متعدد - Many-to-Many) في النمذجة الموجهة للكائنات، حيث تسمح بتخزين بيانات تخص العلاقة نفسها (مثل تاريخ التسجيل أو الدرجة) بدلاً من إجبارها على التواجد في أحد الكيانين.
An Associative Class elegantly resolves Many-to-Many relationships in object-oriented modeling by allowing data specific to the relationship (like registration date or grade) to be stored within the association itself, rather than forcing it into either participating class.
لماذا لا نضع سمة 'الدرجة' (Grade) في فئة الطالب أو فئة المقرر؟ Why don't we put the 'Grade' attribute in the Student class or the Course class?
لأن الدرجة لا تصف الطالب وحده ولا المقرر وحده، بل تصف حدث تسجيل هذا الطالب المحدد في هذا المقرر المحدد، لذا يجب وضعها في فئة ترابطية (Registration).
Because the grade does not describe the student alone nor the course alone; it describes the specific event of that student registering for that course, so it belongs in an Associative Class (Registration).
8 التعميم وتعدد الأشكال
8 Generalization and Polymorphism
التعميم (Generalization) هو استخراج الخصائص المشتركة في فئة عليا (Superclass)، وتعدد الأشكال (Polymorphism) يسمح بتنفيذ نفس العملية بطرق مختلفة في الفئات الفرعية.
Generalization abstracts common features into a Superclass, and Polymorphism allows the same operation to be implemented differently in subclasses.
التعميم: يُمثل بخط صلب ينتهي بسهم يشير للفئة العليا. الفئات الموروثة تسمى فئات فرعية (Subclasses).
الفئات المجردة (Abstract classes): ليس لها مثيلات مباشرة، بينما الفئات الملموسة (Concrete classes): يمكن إنشاء مثيلات منها.
القيود الدلالية: متداخلة (Overlapping) أو منفصلة (Disjoint)، وكاملة (Complete) أو غير كاملة (Incomplete).
تعدد الأشكال (Polymorphism): نفس العملية قد تُطبق على فئات مختلفة بطرق مختلفة.
العملية المجردة (Abstract operation): تحدد شكل العملية دون تنفيذها (التنفيذ يسمى Method).
Generalization: Shown as a solid line with an arrow pointing to the superclass. Inheriting classes are Subclasses.
Abstract classes: Have no direct instances, whereas Concrete classes: can have direct instances.
Semantic Constraints: Overlapping vs Disjoint, Complete vs Incomplete.
Polymorphism: The same operation may apply to two or more classes in different ways.
Abstract operation: Defines the protocol of the operation, but not its implementation (the implementation is called a Method).
تعدد الأشكال يعزز قابلية التوسع في الأنظمة.
على سبيل المثال، عملية calc-tuition() يمكن تعريفها كعملية مجردة في الفئة العليا Student، ويتم تنفيذها (Method) بشكل مختلف في الفئة الفرعية Graduate Student مقارنة بـ Undergrad Student، دون الحاجة لتغيير الكود المستدعي.
Polymorphism enhances system extensibility.
For example, calc-tuition() can be defined as an abstract operation in the Student superclass, and implemented (Method) differently in Graduate Student vs Undergrad Student, without changing the calling code.
ما الفرق بين القيد المنفصل (Disjoint) والمتداخل (Overlapping) في التعميم؟ What is the difference between Disjoint and Overlapping constraints in generalization?
المنفصل يعني أن الكائن يمكن أن ينتمي لفئة فرعية واحدة فقط، بينما المتداخل يعني أن الكائن يمكن أن ينتمي لأكثر من فئة فرعية في نفس الوقت.
Disjoint means an object can belong to only one subclass, while Overlapping means an object can belong to multiple subclasses simultaneously.
9 مفاهيم التجميع والتكوين
9 Aggregation and Composition Concepts
التجميع (Aggregation) هو علاقة 'جزء-من' ضعيفة (معين مفرغ)، بينما التكوين (Composition) هو علاقة قوية حيث تموت الأجزاء بموت الكيان الكلي (معين ممتلئ).
Aggregation is a weak 'part-of' relationship (hollow diamond), while Composition is a strong relationship where parts die with the whole (solid diamond).
التجميع (Aggregation): علاقة 'جزء-من' (part-of) بين كائن مكون وكائن مجمع. تُمثل بـ معين مفرغ (hollow diamond) عند نهاية الكائن المجمع.
التكوين (Composition): شكل أقوى من التجميع، حيث تنتمي الأجزاء إلى كائن كلي واحد فقط، وتحيا وتموت معه. تُمثل بـ معين ممتلئ (solid diamond).
في التكوين، التعددية عند نهاية الكائن المجمع لا يمكن أن تتجاوز واحداً، وحذف الكائن الكلي يؤدي تلقائياً إلى حذف مكوناته (Cascading deletion).
Aggregation: A 'part-of' relationship between a component and an aggregate object. Represented with a hollow diamond at the aggregate end.
Composition: A stronger form of aggregation where parts belong to only one whole object, and live and die with it. Represented with a solid diamond.
In composition, multiplicity on the aggregate end may not exceed one, and deletion of the aggregate object cascades to its components.
التمييز بينهما حاسم في إدارة الذاكرة وقواعد البيانات.
في التكوين (مثل علاقة المبنى بالغرفة)، إذا تم هدم المبنى، الغرف تختفي.
في التجميع (مثل علاقة الجامعة بالكلية)، قد تستمر الكلية في الوجود ككيان إداري حتى لو تغير هيكل الجامعة.
The distinction is crucial for memory and database management.
In Composition (e.g., Building and Room), if the building is destroyed, the rooms cease to exist.
In Aggregation (e.g., University and School), the school might continue to exist as an administrative entity even if the university structure changes.
| التجميعAggregation | التكوينComposition | |
|---|---|---|
| قوة العلاقةRelationship Strength | علاقة جزء-من أضعفWeaker part-of relationship | علاقة جزء-من أقوىStronger part-of relationship |
| الرمز في UMLUML Symbol | معين مفرغ (Hollow diamond)Hollow diamond | معين ممتلئ (Solid diamond)Solid diamond |
| دورة حياة الأجزاءParts Lifecycle | مستقلة عن الكيان الكليIndependent of the whole | تحيا وتموت مع الكيان الكليLive and die with the whole object |
هل علاقة السيارة بالمحرك تعتبر تجميعاً أم تكويناً في نظام إدارة المخزون لورشة صيانة؟ Is the relationship between a Car and an Engine considered Aggregation or Composition in a repair shop inventory system?
تعتبر تجميعاً (Aggregation)، لأن المحرك يمكن إزالته من السيارة وبيعه أو تركيبه في سيارة أخرى، فهو لا يموت بموت السيارة.
It is considered Aggregation, because the engine can be removed from the car and sold or installed in another car; it does not die with the car.