CS350 · مراجعة شاملة

مراجعة الاختبار النصفي - قواعد البيانات

يغطي منهج الاختبار من الوحدة 1 إلى 6

الوحدة 1 الوحدة 2 الوحدة 3 الوحدة 4 الوحدة 5 الوحدة 6 المعادلات المقارنات خزنة الامتحان

1 مقدمة في قواعد البيانات ومستخدميها

فهم المكونات الأساسية لبيئة قواعد البيانات، والتمييز بين البيانات والبرامج، ومعرفة متى يكون استخدام DBMS ضرورياً أو غير ضروري.

1.1 التعريفات الأساسية لقواعد البيانات

البيانات هي الحقائق، وقاعدة البيانات هي تجميعها، ونظام الإدارة (DBMS) هو البرنامج الذي يتحكم بها، تماماً مثل المكتبة والكتب وأمين المكتبة.

تتكون بيئة قواعد البيانات من عدة مصطلحات أساسية:

البيانات (Data) وهي حقائق معروفة يمكن تسجيلها ولها معنى ضمني.

قاعدة البيانات (Database) هي مجموعة من البيانات المترابطة.

نظام إدارة قواعد البيانات (DBMS) هو نظام برمجي محوسب يتيح للمستخدمين إنشاء وصيانة قاعدة البيانات.

عندما نجمع بين قاعدة البيانات وبرنامج DBMS، نحصل على نظام قاعدة البيانات (Database System).

1.2 الخصائص الرئيسية لنهج قواعد البيانات

قواعد البيانات تصف نفسها، تفصل البيانات عن البرامج، تدعم وجهات نظر متعددة، وتسمح لعدة مستخدمين بالعمل معاً في نفس الوقت.

يتميز نهج قواعد البيانات بأربع خصائص رئيسية:

  1. الطبيعة الوصفية الذاتية (Self-describing): حيث يخزن النظام وصفاً لنفسه (البيانات الوصفية).
  2. العزل بين البرامج والبيانات (Insulation): ويتحقق من خلال تجريد البيانات (Data Abstraction)، مما يوفر استقلالية البرامج عن البيانات.
  3. دعم وجهات نظر متعددة (Multiple views): كل مستخدم يرى فقط البيانات التي تهمه.
  4. مشاركة البيانات ومعالجة المعاملات متعددة المستخدمين: السماح لعدة مستخدمين بالوصول المتزامن مع ضمان التحكم في التزامن (Concurrency control).

1.3 أنواع مستخدمي قواعد البيانات (الممثلون على المسرح)

ينقسم المستخدمون إلى: مدير (DBA) يتحكم بالنظام، مصمم يبني الهيكل، ومستخدم نهائي (End-user) يتعامل مع البيانات يومياً.

يوجد عدة أنواع من المستخدمين:

  1. مديرو قواعد البيانات (DBA): مسؤولون عن التصريح بالوصول، مراقبة الاستخدام، وتوفير الموارد.
  2. مصممو قواعد البيانات: مسؤولون عن تحديد الهيكل والقيود.
  3. المستخدمون النهائيون (End-users): وهم من يستخدمون البيانات، وينقسمون إلى:
    • عرضيون (Casual): وصول متقطع.
    • سذج/نمطيون (Naïve/Parametric): الشريحة الأكبر، يستخدمون برامج جاهزة (Canned transactions) مثل موظفي البنوك.
    • متمرسون (Sophisticated): محللون ومهندسون يستخدمون أدوات متقدمة.
    • مستقلون (Stand-alone): يديرون قواعد بيانات شخصية.

1.4 متى لا نستخدم نظام إدارة قواعد البيانات

لا تستخدم DBMS إذا كان تطبيقك بسيطاً جداً، أو يتطلب استجابة فورية حرجة (Real-time)، أو لا يحتاج لمشاركة البيانات بين عدة مستخدمين.

رغم فوائد DBMS، إلا أن له تكاليف (Inhibitors) مثل الاستثمار الأولي المرتفع والحاجة لأجهزة إضافية، بالإضافة إلى العبء الإضافي (Overhead) لتوفير الأمان والتحكم في التزامن.

قد يكون DBMS غير ضروري إذا: كانت قاعدة البيانات والتطبيقات بسيطة ومحددة جيداً ولا يتوقع تغيرها، أو إذا كانت هناك متطلبات صارمة للوقت الفعلي (Real-time) قد يعيقها عبء النظام، أو إذا لم يكن الوصول المتعدد مطلوباً.

وقد لا يكون كافياً إذا: كانت هناك قيود في النمذجة تمنع التعامل مع بيانات معقدة، أو إذا كان المستخدمون يحتاجون عمليات خاصة لا يدعمها النظام.

2 مفاهيم نظام قواعد البيانات ومعماريته

فصل الهيكل (المخطط) عن البيانات (الحالة)، واستخدام معمارية المخططات الثلاثة لتحقيق استقلالية البيانات، وفهم تطور معماريات الأنظمة.

2.1 نماذج البيانات (Data Models)

مجموعة من المفاهيم التي تصف بنية قاعدة البيانات وعملياتها وقيودها، تشبه المخطط الهندسي للمبنى.

نموذج البيانات يحدد كيفية تنظيم البيانات. يتضمن:

  1. البنية (عناصر البيانات، الكيانات، العلاقات).
  2. القيود (لضمان صحة البيانات).
  3. العمليات (الأساسية مثل الإدراج والحذف، والمخصصة مثل حساب المعدل).

تنقسم النماذج إلى: مفاهيمية (عالية المستوى، قريبة من فهم المستخدم)، مادية (منخفضة المستوى، تصف تفاصيل التخزين)، وتنفيذية/تمثيلية (بين الاثنين، تستخدم في الأنظمة التجارية مثل النموذج العلائقي).

2.2 مخطط قاعدة البيانات مقابل حالة قاعدة البيانات

المخطط هو الهيكل الثابت (النية)، بينما الحالة هي البيانات المتغيرة في لحظة معينة (الامتداد).

مخطط قاعدة البيانات (Schema): هو وصف بنية قاعدة البيانات والقيود وأنواع البيانات. يتغير نادراً جداً ويسمى أيضاً (Intension).

حالة قاعدة البيانات (State): هي البيانات الفعلية المخزنة في لحظة زمنية معينة. تتغير مع كل عملية تحديث أو إدراج، وتسمى أيضاً (Extension) أو (Snapshot).

الحالة الابتدائية هي عند تحميل البيانات لأول مرة، والحالة الصالحة هي التي تلبي جميع قيود المخطط.

2.3 معمارية المخططات الثلاثة واستقلالية البيانات

معمارية تفصل قاعدة البيانات إلى ثلاثة مستويات: داخلي (تخزين)، مفاهيمي (منطق)، وخارجي (عروض المستخدمين) لتحقيق استقلالية البيانات.

تم اقتراح هذه المعمارية لدعم استقلالية البيانات وتعدد العروض. تتكون من:

  1. المستوى الداخلي (Internal): يصف التخزين المادي ومسارات الوصول (الفهارس).
  2. المستوى المفاهيمي (Conceptual): يصف البنية والقيود لقاعدة البيانات بأكملها لمجتمع المستخدمين.
  3. المستوى الخارجي (External): يصف عروضاً مخصصة لمجموعات مختلفة من المستخدمين.

استقلالية البيانات تعني القدرة على تغيير مخطط في مستوى معين دون الحاجة لتغيير المخطط في المستوى الأعلى منه (استقلالية منطقية ومادية).

2.4 لغات أنظمة إدارة قواعد البيانات

لغة تعريف البيانات (DDL) لبناء الهيكل، ولغة معالجة البيانات (DML) للتعامل مع المحتوى (استرجاع وتحديث).

DDL (لغة تعريف البيانات): يستخدمها مدير قاعدة البيانات (DBA) والمصممون لتحديد المخطط المفاهيمي (وأحياناً الداخلي والخارجي). نظرياً يوجد VDL لتعريف العروض و SDL لتعريف التخزين، لكن عملياً تدمج في DDL.

DML (لغة معالجة البيانات): تستخدم للاسترجاع والتحديث. تنقسم إلى:

  1. عالية المستوى/تصريحية (مثل SQL): تحدد 'ماذا' نريد وليس 'كيف'، وتتعامل مع مجموعة سجلات.
  2. منخفضة المستوى/إجرائية: يجب تضمينها في لغة برمجة وتتعامل مع سجل واحد في كل مرة (تحتاج إلى حلقات تكرار).

2.5 معماريات أنظمة إدارة قواعد البيانات

تطورت من المركزية (جهاز واحد يفعل كل شيء) إلى ثنائية الطبقات (عميل وخادم) ثم ثلاثية الطبقات (إضافة خادم تطبيقات للويب والأمان).

  1. المعمارية المركزية: يدمج كل شيء (البرامج، العتاد، واجهة المستخدم) في نظام كمبيوتر واحد.
  2. معمارية خادم-عميل ثنائية الطبقات (2-tier): العميل يتعامل مع واجهة المستخدم ويتصل مباشرة بخادم قاعدة البيانات (عبر ODBC/JDBC).
  3. معمارية ثلاثية الطبقات (3-tier): شائعة في تطبيقات الويب. تضيف طبقة وسيطة (خادم تطبيقات/ويب) بين العميل وقاعدة البيانات. العميل لا يتصل بقاعدة البيانات مباشرة، مما يعزز الأمان ويخزن منطق الأعمال (Business Logic) في الطبقة الوسيطة.

2.6 تاريخ نماذج البيانات

تطورت النماذج من الشبكي والهرمي (معقدة وتعتمد على المؤشرات) إلى العلائقي (جداول بسيطة ومرنة) ثم الكائني والأنظمة الحديثة (NOSQL).

  1. النموذج الشبكي (Network): ظهر في الستينات (مثل نظام IDS). يمثل العلاقات المعقدة لكنه يعتمد على لغة ملاحية معقدة ومؤشرات متشابكة.
  2. النموذج الهرمي (Hierarchical): طورته IBM (نظام IMS). يخزن البيانات بشكل شجري، ممتاز للبيانات الهرمية لكنه سيء للعلاقات المتعددة.
  3. النموذج العلائقي (Relational): اقترحه E.F. Codd عام 1970. يستخدم الجداول (SQL) وهو المهيمن حالياً.
  4. النماذج الكائنية (Object-oriented): تدمج قواعد البيانات مع لغات البرمجة الكائنية (مثل C++).
  5. أنظمة البيانات الضخمة (NOSQL): مثل Key-value، Document، Graph، Column-based.

3 النموذج العلائقي

تمثيل البيانات كجداول (علاقات) مبنية على أسس رياضية صارمة، وتطبيق قيود النزاهة لضمان دقة وصحة البيانات.

3.1 التعريفات الأساسية للنموذج العلائقي

النموذج العلائقي يمثل البيانات كجداول (علاقات) تتكون من صفوف (مجموعات قيم) وأعمدة (صفات).

يعتمد النموذج العلائقي الرسمي على نظرية المجموعات ومنطق الفئة الأولى. عملياً، يتم تمثيله باستخدام لغة SQL.

يتكون من: العلاقة (Relation) وهي الجدول، الصف (Tuple) وهو مجموعة مرتبة من القيم تمثل كياناً أو علاقة في العالم الحقيقي، الصفة (Attribute) وهي عنوان العمود الذي يعطي دلالة لمعنى البيانات، والمجال (Domain) وهو مجموعة القيم الصالحة التي يمكن أن تأخذها الصفة.

3.2 مخطط العلاقة مقابل حالة العلاقة

المخطط هو هيكل الجدول (أسماؤه وأعمدته)، بينما الحالة هي البيانات الفعلية الموجودة فيه في لحظة معينة.

مخطط العلاقة (Relation Schema): يُرمز له بـ R(A1, A2, ..., An)، حيث R هو اسم العلاقة و A هي الصفات. يمثل وصفاً للعلاقة.
حالة العلاقة (Relation State): يُرمز لها بـ r(R)، وهي مجموعة محددة من الصفوف (Tuples) في العلاقة في لحظة معينة. رياضياً، هي مجموعة فرعية من الجداء الديكارتي (Cartesian product) لمجالات صفاتها.

حالة العلاقة هي مجموعة فرعية من الجداء الديكارتي لمجالات الصفات. \[r(R) \subset dom(A_1) \times dom(A_2) \times ... \times dom(A_n)\]

3.3 خصائص العلاقات

الصفوف في العلاقة غير مرتبة، والقيم داخلها يجب أن تكون ذرية (لا يمكن تجزئتها).

تتميز العلاقات بعدة خصائص:

  1. ترتيب الصفوف: الصفوف غير مرتبة لأن العلاقة رياضياً هي مجموعة (Set) من الصفوف.
  2. ترتيب الصفات: في التعريف القياسي، الصفات والقيم مرتبة، ولكن في التعريف الأعم يمكن اعتبار الصف كمجموعة غير مرتبة من أزواج (اسم الصفة، القيمة).
  3. القيم الذرية: كل قيمة في الصف يجب أن تكون ذرية (Atomic) ومستمدة من مجال الصفة.
  4. القيم الفارغة (NULL): تُستخدم لتمثيل القيم غير المعروفة أو غير القابلة للتطبيق.

3.4 قيود المفاتيح

المفتاح هو صفة أو مجموعة صفات تميز كل صف في الجدول بشكل فريد.

المفتاح الفائق (Superkey): مجموعة من الصفات التي تضمن عدم وجود صفين متطابقين في هذه الصفات.

المفتاح (Key / Candidate Key): هو مفتاح فائق أصغري (Minimal)، أي إذا أزلنا أي صفة منه، يفقد خاصية التفرد.

المفتاح الأساسي (Primary Key): هو أحد المفاتيح المرشحة يتم اختياره لتعريف الصفوف بشكل فريد، وعادة ما يُوضع تحته خط في المخطط.

المفاتيح الثانوية (Secondary/Unique Keys): هي المفاتيح المرشحة الأخرى التي لم يتم اختيارها كمفتاح أساسي.

لأي صفين مختلفين، يجب أن تكون قيمة المفتاح الفائق مختلفة. \[t_1.SK \neq t_2.SK\]

3.5 تكامل الكيان والتكامل المرجعي

تكامل الكيان يمنع المفتاح الأساسي من أن يكون فارغاً، والتكامل المرجعي يضمن أن المفتاح الأجنبي يشير إلى سجل موجود فعلاً.

تكامل الكيان (Entity Integrity): ينص على أن صفات المفتاح الأساسي (PK) لا يمكن أن تحتوي على قيم فارغة (NULL) في أي صف، لأن المفتاح الأساسي يُستخدم لتعريف الصفوف.

التكامل المرجعي (Referential Integrity): قيد يتضمن علاقتين. يضمن أن قيمة المفتاح الأجنبي (FK) في العلاقة المرجعية (Referencing) يجب أن تتطابق مع قيمة مفتاح أساسي (PK) موجودة في العلاقة المرجوع إليها (Referenced)، أو أن تكون القيمة فارغة (NULL) إذا لم يكن جزءاً من مفتاح أساسي.

قيمة المفتاح الأجنبي يجب أن تساوي مفتاحاً أساسياً موجوداً أو تكون فارغة. \[t_1.FK = t_2.PK \lor t_1.FK = NULL\]

3.6 عمليات التحديث وانتهاكات القيود

عند إدراج أو حذف أو تعديل البيانات، يجب التأكد من عدم خرق أي من قيود قاعدة البيانات.

العمليات الأساسية لتعديل قاعدة البيانات هي: INSERT (إدراج)، DELETE (حذف)، و UPDATE (تعديل).

في حالة حدوث انتهاك للقيود، يمكن اتخاذ عدة إجراءات:

  1. RESTRICT / REJECT: إلغاء العملية التي تسبب الانتهاك.
  2. CASCADE: نشر التحديث أو الحذف تلقائياً إلى السجلات المرتبطة.
  3. SET NULL: تعيين المفاتيح الأجنبية المرتبطة إلى قيمة فارغة (إذا كان مسموحاً).

4 نموذج الكيان والعلاقة - الجزء الأول

مقدمة في التصميم المفاهيمي لقواعد البيانات باستخدام نموذج ER، مع التركيز على الكيانات، السمات، والعلاقات الأساسية.

4.1 عملية تصميم قاعدة البيانات

عملية تحويل متطلبات العالم الحقيقي إلى مخطط قاعدة بيانات منظم، مثل المهندس المعماري الذي يرسم مخططاً قبل بناء المنزل.

تتكون عملية التصميم من نشاطين رئيسيين: تصميم مخطط قاعدة البيانات وتصميم برامج التطبيقات.

يركز هذا المفهوم على التصميم المفاهيمي (Conceptual Design)، والذي يأتي بعد جمع المتطلبات وتحليلها. في هذه المرحلة، يتم استخدام نماذج بيانات عالية المستوى مثل نموذج ER لإنشاء مخطط مفاهيمي مستقل عن نظام إدارة قواعد البيانات (DBMS) المحدد.

4.2 الكيانات والسمات

الكيان هو شيء في العالم الحقيقي والسمات هي خصائصه، تماماً مثل الاسم (Noun) والصفات (Adjectives) في الجملة.

الكيانات (Entities): هي كائنات أو أشياء محددة في العالم المصغر (mini-world) يتم تمثيلها في قاعدة البيانات (مثل: الموظف جون سميث، قسم الأبحاث).

السمات (Attributes): هي الخصائص المستخدمة لوصف الكيان. كل سمة لها مجموعة قيم (Value Set) أو نوع بيانات مرتبط بها (مثل: عدد صحيح، نص).

أنواع السمات تشمل:

  1. بسيطة (Simple/Atomic): قيمة واحدة غير قابلة للتجزئة (مثل: رقم الضمان الاجتماعي SSN).
  2. مركبة (Composite): تتكون من عدة مكونات (مثل: العنوان يتكون من مدينة، شارع، رقم المبنى).
  3. متعددة القيم (Multi-valued): يمكن أن يكون للكيان قيم متعددة لهذه السمة (مثل: ألوان السيارة، الشهادات السابقة)، ويُشار إليها بـ {السمة}.

4.3 أنواع الكيانات، مجموعات الكيانات، والمفاتيح

نوع الكيان هو القالب ومجموعة الكيانات هي البيانات الفعلية، مثل قالب البسكويت وقطع البسكويت التي يصنعها.

نوع الكيان (Entity Type): يجمع الكيانات التي لها نفس السمات الأساسية (مثل: نوع الكيان EMPLOYEE). يُرسم كمستطيل في مخطط ER.

مجموعة الكيانات (Entity Set): هي مجموعة الكيانات الفردية المخزنة في قاعدة البيانات في وقت معين (تمثل الحالة الحالية).

السمة المفتاحية (Key Attribute): سمة يجب أن يكون لها قيمة فريدة (متميزة) لكل كيان في مجموعة الكيانات (مثل: SSN للموظف). يمكن أن يكون المفتاح مركباً (مثل: رقم لوحة السيارة يتكون من الرقم والولاية)، ويمكن أن يكون لنوع الكيان أكثر من مفتاح واحد. تُوضع خط تحت السمة المفتاحية في مخططات ER.

4.4 العلاقات، أنواع العلاقات، ومجموعات العلاقات

العلاقة تربط بين الكيانات، وتعمل مثل الأفعال التي تربط الأسماء معاً في القصة.

العلاقة (Relationship): تربط بين كيانين متميزين أو أكثر بمعنى محدد (مثل: الموظف جون يعمل في مشروع X).

نوع العلاقة (Relationship Type): هو وصف المخطط للعلاقة، ويحدد اسم العلاقة وأنواع الكيانات المشاركة. يُعرض في مخطط ER كصندوق على شكل معين (Diamond) متصل بخطوط مستقيمة بأنواع الكيانات المشاركة.

مجموعة العلاقات (Relationship Set): هي المجموعة الحالية من حالات العلاقة (Relationship instances) الممثلة في قاعدة البيانات.

درجة العلاقة (Degree): هي عدد أنواع الكيانات المشاركة في العلاقة. العلاقة بين كيانين تسمى علاقة ثنائية (Binary).

4.5 العلاقات العودية (الذاتية)

علاقة يشارك فيها الكيان مع نفسه بأدوار مختلفة، مثل شجرة العائلة حيث يكون الشخص والداً وطفلاً في نفس الوقت.

العلاقة العودية (Recursive Relationship): هي نوع علاقة يشارك فيها نفس نوع الكيان مرتين في دورين متميزين (distinct roles).

مثال كلاسيكي هو علاقة الإشراف (SUPERVISION) بين الموظفين. يشارك كيان EMPLOYEE مرتين:

  1. دور المشرف (Supervisor / Boss).
  2. دور الخاضع للإشراف (Supervisee / Subordinate).

في هذه الحالة، من الضروري التمييز بين الأدوار في حالة العلاقة (Relationship instance) لمعرفة من يشرف على من. في مخطط ER، تُرسم خطوط العلاقة من المعين عائدة إلى نفس مستطيل الكيان، مع كتابة أسماء الأدوار على الخطوط.

4.6 أنواع الكيانات الضعيفة

كيان لا يمكنه الوجود بدون مالك، تماماً مثل الظل الذي يختفي بدون الجسم الذي يلقيه.

الكيان الضعيف (Weak Entity Type): هو نوع كيان لا يحتوي على سمة مفتاحية خاصة به. لا يمكن تحديد كياناته الفردية إلا من خلال علاقتها بكيانات أخرى.

يجب أن يشارك الكيان الضعيف في علاقة تعريف (Identifying Relationship) مع نوع كيان مالك (Owner / Identifying Entity Type).

يتم تحديد الكيانات الفردية الضعيفة من خلال مزيج من:

  1. الكيان المالك الذي ترتبط به.
  2. مفتاح جزئي (Partial Key) للكيان الضعيف.

مثال: كيان DEPENDENT (المُعال) هو كيان ضعيف. يتم تحديده من خلال الموظف (المالك) الذي يعوله، بالإضافة إلى الاسم الأول للمُعال (المفتاح الجزئي). في مخطط ER، يُرسم الكيان الضعيف بمستطيل مزدوج الخطوط، وعلاقة التعريف بمعين مزدوج الخطوط، والمفتاح الجزئي بخط متقطع تحته.

5 نموذج الكيانات والعلاقات (الجزء الثاني) والنموذج الموسع (EER)

تغطية متقدمة لنموذج ER تشمل القيود وصيغة (min, max)، ومقدمة لنموذج EER الذي يضيف مفاهيم الوراثة والتخصيص.

5.1 قيود العلاقات (Relationship Constraints)

قواعد تحدد عدد مرات مشاركة الكيان في العلاقة، وتعمل مثل حدود السعة على الجسر.

توجد نوعان رئيسيان من القيود على العلاقات الثنائية:

  1. نسبة التعددية (Cardinality Ratio): تحدد الحد الأقصى للمشاركة (1:1، 1:N، M:N).
  2. قيد الاعتمادية/المشاركة (Existence Dependency/Participation): يحدد الحد الأدنى للمشاركة، إما صفر (مشاركة اختيارية) أو واحد فأكثر (مشاركة إلزامية/كلية).

5.2 صيغة (min, max)

طريقة دقيقة لتحديد الحد الأدنى والأقصى للمشاركة، مثل وضع أرضية وسقف للميزانية.

تحدد هذه الصيغة أن كل كيان e في الفئة E يشارك في العلاقة R بحد أدنى (min) وحد أقصى (max) من المرات. القيمة الافتراضية هي (0, n).

يجب أن يكون min ≤ max، و min ≥ 0، و max ≥ 1. مثال: (1,1) تعني مشاركة إلزامية لمرة واحدة فقط.

شروط قيم الحد الأدنى والأقصى \[0 \le min \le max \quad \text{and} \quad max \ge 1\]

5.3 العلاقات العودية وخصائص العلاقات

علاقات تربط الكيان بنفسه أو تحمل بيانات، مثل ظرف موجه لنفسك يحمل أيضاً قيمة الطابع.

العلاقات العودية: يشارك نفس الكيان في العلاقة بأدوار مختلفة (مثل موظف يدير موظفاً آخر). يجب كتابة 'أسماء الأدوار' (Role Names) على الخطوط لتمييز المشاركات.

خصائص العلاقات: يمكن أن تمتلك العلاقة خصائص (مثل عدد الساعات في علاقة 'يعمل_على'). تُستخدم غالباً مع علاقات M:N، أما في علاقات 1:N فيمكن نقل الخاصية إلى الكيان في جهة N.

5.4 مخططات الفئات في UML

طريقة بديلة لتمثيل قواعد البيانات تُستخدم في هندسة البرمجيات، مثل استخدام لهجة مختلفة لقول نفس القصة.

في UML، تُرسم الفئة كمربع مقسم لثلاثة أجزاء: الاسم، الخصائص، والعمليات (Operations - لا تُستخدم في ER الأساسي).

العلاقات تُسمى Associations وتُرسم كخطوط. التعددية (Multiplicities) تُكتب بصيغة min..max، ولكن توضع على الجانب المعاكس مقارنة بـ ER. الرمز * يعني N (بدون حد أقصى).

التجميع (Aggregation) هو علاقة بين كائن وأجزائه ويُرسم بمعين صغير.

5.5 العلاقات ذات الدرجات العليا (n-ary)

علاقات تربط ثلاثة كيانات أو أكثر في نفس الوقت، مثل تقاطع ثلاثي حيث تلتقي كل الطرق في وقت واحد.

درجة العلاقة هي عدد الكيانات المشاركة فيها. الدرجة 2 ثنائية، 3 ثلاثية (Ternary)، و n تسمى n-ary.

بشكل عام، العلاقة الثلاثية لا تكافئ ثلاث علاقات ثنائية، لأنها تمثل معلومة مختلفة (التركيبة المحددة للثلاثة معاً).

تحديد القيود (min, max) في هذه العلاقات أصعب، حيث يشير الرقم 1 إلى أن الكيان يشارك في مثيل علاقة واحد فقط لتركيبة معينة من الكيانات الأخرى.

5.6 الفئات الفرعية والعليا والوراثة (EER)

تسلسل هرمي حيث ترث الكيانات المحددة سمات من كيان عام، تماماً مثل الأطفال الذين يرثون الجينات من والديهم.

نموذج EER يوسع ER لدعم التجريد.

الفئة الفرعية (Subclass): مجموعة فرعية من كيانات الفئة العليا (Superclass) لها خصائص مميزة. العلاقة بينهما تسمى IS-A (السكرتير 'هو' موظف).

الوراثة (Inheritance): أي كيان في الفئة الفرعية يرث تلقائياً جميع الخصائص (Attributes) والعلاقات (Relationships) الخاصة بالفئة العليا، بالإضافة إلى خصائصه المحلية (Local attributes).

5.7 التخصيص والتعميم

التقسيم من أعلى لأسفل مقابل التجميع من أسفل لأعلى، مثل التكبير لرؤية التفاصيل مقابل التصغير لرؤية الصورة الكبيرة.

التخصيص (Specialization): عملية تعريف مجموعة من الفئات الفرعية بناءً على خصائص مميزة (مثل تقسيم الموظفين حسب نوع الوظيفة). تُرسم بخطوط متصلة بدائرة تحتوي رمز المجموعة الفرعية.

التعميم (Generalization): العملية العكسية؛ تجميع عدة فئات تشترك في خصائص معينة لتكوين فئة عليا (مثل تجميع 'سيارة' و'شاحنة' في فئة 'مركبة').

6 نموذج الكيان والعلاقة المحسن وتصميم قواعد البيانات العلائقية

تطبيق قيود EER المتقدمة وتحويل المخططات المفاهيمية (ER/EER) إلى جداول علائقية فعلية باستخدام خوارزمية منهجية.

6.1 التخصيص والتعميم (Specialization & Generalization)

تقسيم أو تجميع الكيانات بناءً على السمات، مثل فرز مجموعة أوراق اللعب حسب النوع أو دمجها في كومة واحدة.

في نموذج EER، التخصيص (Specialization) هو عملية تعريف مجموعة من الفئات الفرعية (Subclasses) لنوع كيان معين (Superclass) بناءً على خصائص مميزة. إنها عملية تحسين مفاهيمية من أعلى إلى أسفل (Top-down). على سبيل المثال، يمكن تخصيص الكيان EMPLOYEE إلى SECRETARY, TECHNICIAN, ENGINEER.

التعميم (Generalization) هو العملية العكسية؛ حيث نبدأ بأنواع كيانات متعددة ونقوم بتعميمها في كيان أعلى (Superclass) يجمع الخصائص المشتركة (Bottom-up). ترث الفئة الفرعية جميع السمات والعلاقات الخاصة بالفئة العليا.

6.2 قيود التخصيص والتعميم (Constraints)

قواعد تملي ما إذا كانت الفئات الفرعية تتداخل أو إلزامية، مثل تحديد ما إذا كان الطالب يمكنه التخصص المزدوج أو يجب عليه اختيار تخصص واحد على الأقل.

يوجد قيدان أساسيان يطبقان على التخصيص/التعميم:

  1. قيد الانفصال (Disjointness Constraint): يحدد ما إذا كانت الفئات الفرعية منفصلة. إذا كانت منفصلة (Disjoint - يُرمز لها بـ d)، فإن الكيان يمكن أن يكون عضواً في فئة فرعية واحدة على الأكثر. إذا لم تكن منفصلة (Overlapping - يُرمز لها بـ o)، يمكن للكيان أن ينتمي لأكثر من فئة فرعية في نفس الوقت.
  2. قيد الاكتمال (Completeness Constraint): يحدد ما إذا كان كل كيان في الفئة العليا يجب أن يكون عضواً في فئة فرعية على الأقل. إذا كان كلياً (Total - خط مزدوج)، يجب أن ينتمي الكيان لفئة فرعية. إذا كان جزئياً (Partial - خط مفرد)، يُسمح للكيان بألا ينتمي لأي فئة فرعية.
اتحاد جميع الفئات الفرعية يساوي الفئة العليا في حالة الاكتمال الكلي. \[S_1 \cup S_2 \cup \dots \cup S_n = G \quad \text{(Total Completeness)}\]

6.3 الفئات وأنواع الاتحاد (Categories / UNION Types)

فئة فرعية تمثل اتحاداً لفئات عليا مختلفة، مثل 'مالك المركبة' الذي يمكن أن يكون شخصاً أو شركة.

في بعض الحالات، نحتاج إلى نمذجة علاقة فئة عليا/فئة فرعية واحدة مع أكثر من فئة عليا واحدة، حيث تمثل الفئات العليا أنواع كيانات مختلفة. تُسمى هذه الفئة الفرعية الفئة (Category) أو نوع الاتحاد (UNION TYPE).

على سبيل المثال، في قاعدة بيانات تسجيل المركبات، يمكن أن يكون المالك (OWNER) إما شخصاً (PERSON)، أو بنكاً (BANK)، أو شركة (COMPANY). يتم إنشاء الفئة OWNER لتمثيل مجموعة فرعية من اتحاد هذه الكيانات الثلاثة. يُرمز لها في مخطط EER بحرف 'U' داخل دائرة.

الفئة T هي مجموعة فرعية من اتحاد الفئات العليا D1 إلى Dn. \[T \subseteq (D_1 \cup D_2 \cup \dots \cup D_n)\]

6.4 خوارزمية التحويل من ER إلى نموذج علائقي (ER-to-Relational Mapping)

خوارزمية من 7 خطوات لتحويل المخططات إلى جداول، مثل ترجمة مخطط مفاهيمي إلى تعليمات بناء فعلية.

تتكون خوارزمية التحويل الأساسية من 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) تُحول إلى جدول جديد يحتوي على المفاتيح الأجنبية لجميع الكيانات المشاركة.

6.5 تحويل مفاهيم EER إلى جداول (EER Mapping Steps 8 & 9)

الخطوتان 8 و 9 لتحويل الوراثة والفئات إلى جداول، مثل تحديد ما إذا كنت ستبني خزانة واحدة كبيرة أو عدة خزائن صغيرة.

تُضاف خطوتان لخوارزمية التحويل للتعامل مع EER:

  • الخطوة 8: تحويل التخصيص/التعميم. يوجد 4 خيارات:
    • 8A: جداول متعددة (جدول للفئة العليا وجدول لكل فئة فرعية). يعمل مع أي تخصيص.
    • 8B: جداول للفئات الفرعية فقط. يعمل جيداً إذا كان التخصيص كلياً (Total) ومنفصلاً (Disjoint).
    • 8C: جدول واحد مع سمة نوع (Type attribute) واحدة. يعمل فقط مع الفئات الفرعية المنفصلة (Disjoint).
    • 8D: جدول واحد مع سمات نوع متعددة (Boolean attributes). يعمل مع الفئات الفرعية المتداخلة (Overlapping).
  • الخطوة 9: تحويل الفئات (UNION Types). يتم إنشاء جدول جديد للفئة، وبما أن الفئات العليا قد تمتلك مفاتيح مختلفة، يتم إنشاء مفتاح بديل (Surrogate Key) ليكون المفتاح الأساسي لجدول الفئة، ويُضاف كمفتاح أجنبي في جداول الفئات العليا.

مرجع المعادلات

المعادلة / المفهوم الوحدة LaTeX / Notation
حالة العلاقة هي مجموعة فرعية من الجداء الديكارتي لمجالات الصفات. M3 \(r(R) \subset dom(A_1) \times dom(A_2) \times ... \times dom(A_n)\)
لأي صفين مختلفين، يجب أن تكون قيمة المفتاح الفائق مختلفة. M3 \(t_1.SK \neq t_2.SK\)
قيمة المفتاح الأجنبي يجب أن تساوي مفتاحاً أساسياً موجوداً أو تكون فارغة. M3 \(t_1.FK = t_2.PK \lor t_1.FK = NULL\)
شروط قيم الحد الأدنى والأقصى M5 \(0 \le min \le max \quad \text{and} \quad max \ge 1\)
اتحاد جميع الفئات الفرعية يساوي الفئة العليا في حالة الاكتمال الكلي. M6 \(S_1 \cup S_2 \cup \dots \cup S_n = G \quad \text{(Total Completeness)}\)
الفئة T هي مجموعة فرعية من اتحاد الفئات العليا D1 إلى Dn. M6 \(T \subseteq (D_1 \cup D_2 \cup \dots \cup D_n)\)

مقارنة المفاهيم الأساسية

مقارنة بين أنواع المستخدمين النهائيين

المعيار Naïve (Parametric) End-users Sophisticated End-users
طريقة التفاعل مع النظام استخدام برامج ومعاملات جاهزة (Canned transactions) استخدام أدوات متقدمة وحزم برمجيات للتحليل
حجم الشريحة القسم الأكبر من المستخدمين شريحة متخصصة (محللون، مهندسون)

استخدام DBMS مقابل عدم استخدامه

المعيار Using a DBMS Not Using a DBMS
التكلفة الأولية مرتفعة (برمجيات وأجهزة) منخفضة
أداء الوقت الفعلي (Real-time) قد يعاني من تأخير بسبب العبء الإضافي (Overhead) سريع ومباشر (مناسب للمتطلبات الصارمة)
التحكم في التزامن والأمان مدمج وموثوق يجب برمجته يدوياً (عرضة للأخطاء)

استقلالية البيانات المنطقية مقابل المادية

المعيار Logical Data Independence Physical Data Independence
مستوى التغيير تغيير المخطط المفاهيمي تغيير المخطط الداخلي
التأثير على التطبيقات لا تتأثر المخططات الخارجية والتطبيقات لا يتأثر المخطط المفاهيمي
صعوبة التحقيق صعبة جداً أسهل نسبياً

معمارية ثنائية الطبقات مقابل ثلاثية الطبقات

المعيار 2-Tier Architecture 3-Tier Architecture
الطبقة الوسيطة غير موجودة (اتصال مباشر) موجودة (خادم تطبيقات/ويب)
الأمان أقل (العميل يصل للقاعدة مباشرة) أعلى (العميل لا يصل للقاعدة مباشرة)
حالة الاستخدام الشائعة تطبيقات سطح المكتب التقليدية تطبيقات الويب

قاموس البيانات النشط مقابل الخامل

المعيار Active Data Dictionary Passive Data Dictionary
إمكانية الوصول يتم الوصول إليه بواسطة برامج DBMS والمستخدمين يتم الوصول إليه بواسطة المستخدمين/DBA فقط

المصطلحات غير الرسمية مقابل المصطلحات الرسمية

المعيار Informal Term Formal Term
الجدول Table Relation
عنوان العمود Column Header Attribute
القيم الممكنة / نوع البيانات Data Type Domain
الصف Row Tuple
تعريف الجدول Table Definition Schema of a Relation
الجدول المعبأ بالبيانات Populated Table State of the Relation

نوع الكيان مقابل مجموعة الكيانات

المعيار Entity Type Entity Set
التعريف وصف المخطط (Schema) والسمات المشتركة. البيانات الفعلية المخزنة في لحظة معينة.
التغير بمرور الوقت ثابت (لا يتغير إلا بتعديل التصميم). متغير (يتغير مع إضافة/حذف الكيانات).

أنواع السمات

المعيار Simple Attribute Composite Attribute Multi-valued Attribute
قابلية التجزئة غير قابل للتجزئة (ذري). قابل للتجزئة إلى مكونات فرعية. غير قابل للتجزئة بالضرورة، لكنه يحمل قيماً متعددة.
أمثلة العمر، الجنس، رقم الضمان الاجتماعي. العنوان (مدينة، شارع)، الاسم (أول، أخير). ألوان السيارة، الشهادات السابقة.

التخصيص مقابل التعميم

المعيار Specialization (التخصيص) Generalization (التعميم)
اتجاه التصميم من أعلى إلى أسفل (Top-down) من أسفل إلى أعلى (Bottom-up)
نقطة البداية فئة عليا واحدة يتم تقسيمها عدة فئات يتم تجميعها
النتيجة في المخطط متطابقة (فئة عليا وفرعية) متطابقة (فئة عليا وفرعية)

التعددية: ER مقابل UML

المعيار ER (min, max) UML Multiplicity
مكان وضع الأرقام بجوار الكيان المعني على الطرف المعاكس للارتباط
صيغة الكتابة (min, max) min..max
رمز اللانهاية N أو M * (نجمة)

قيد الانفصال: منفصل مقابل متداخل

المعيار Disjoint (d) Overlapping (o)
الانتماء للفئات الفرعية فئة فرعية واحدة على الأكثر يمكن أن ينتمي لأكثر من فئة فرعية
الرمز في مخطط EER حرف 'd' داخل دائرة حرف 'o' داخل دائرة
خيار التحويل المفضل (جدول واحد) الخيار 8C (سمة نوع واحدة) الخيار 8D (سمات منطقية متعددة)

الفئة الفرعية المشتركة مقابل الفئة (Category)

المعيار Shared Subclass Category (UNION Type)
العلاقة المنطقية تقاطع (Intersection) الفئات العليا اتحاد (Union) الفئات العليا
شرط الانتماء يجب أن يوجد في *جميع* الفئات العليا يجب أن يوجد في *واحدة على الأقل* من الفئات العليا
المفاتيح الأساسية للفئات العليا يجب أن تمتلك جميع الفئات العليا نفس المفتاح الأساسي يمكن أن تمتلك الفئات العليا مفاتيح مختلفة (يتطلب مفتاح بديل)

🃏 البطاقات التعليمية

🎯 اختبر نفسك

1 / 306 🎯 نتيجتك: 0

حديث البروفيسور

أهلاً بكم يا أبنائي طلاب مقرر CS350 في ليلة الامتحان النصفي. الليلة هي ليلة ربط الخيوط ببعضها البعض، حيث تكتمل الصورة الكبيرة لتصميم قواعد البيانات من الوحدة الأولى وحتى السادسة. دعونا نسترجع رحلتنا معاً: بدأنا في الوحدة الأولى بفهم جوهر قواعد البيانات، ولماذا نستخدمها، وكيف نفصل بين البيانات والبرامج. ثم انتقلنا في الوحدة الثانية إلى المفاهيم والبنية، حيث ركزنا على معمارية المخططات الثلاثة (Three-Schema Architecture) لتحقيق استقلالية البيانات. من الفخاخ الشائعة في الامتحان الخلط بين حالة قاعدة البيانات (State) التي تتغير باستمرار، والمخطط (Schema) الذي يمثل الهيكل الثابت. بعد ذلك، دخلنا في الوحدة الثالثة إلى النموذج العلائقي (Relational Model)، وهو الأساس الرياضي الذي يحول البيانات إلى جداول (Relations) تحكمها قيود التكامل (Integrity Constraints). وهنا يأتي السؤال: كيف نصمم هذه الجداول؟ الإجابة تكمن في الوحدتين الرابعة والخامسة، حيث تعلمنا التصميم المفاهيمي باستخدام نموذج الكيان والعلاقة (ER Model). بدأنا بالكيانات والصفات، ثم تعمقنا في القيود وترميز (min, max)، وصولاً إلى النموذج المحسن (EER Model) للتعامل مع الفئات الفرعية والعلاقات المعقدة. احذروا في الامتحان من إهمال قيود المشاركة والنسبة، فهي تحدد شكل الجداول لاحقاً. أخيراً، تأتي الوحدة السادسة لتتوج كل ما سبق، حيث نتعلم كيفية تحويل (Mapping) المخططات المفاهيمية (ER/EER) إلى جداول علائقية فعلية (Relational Tables) كما درسناها في الوحدة الثالثة. هذا التحويل هو قلب الامتحان النصفي! ركزوا جيداً على قواعد تحويل العلاقات من نوع 1:1 و 1:N و M:N، وكيفية التعامل مع الكيانات الضعيفة. لا تنسوا مراجعة الفروق الدقيقة بين المفتاح الأساسي والمفتاح المرشح في الوحدة الثالثة، وكيف ينعكس ذلك على تصميمكم النهائي. الامتحان يقيس قدرتكم على التفكير المنطقي المتسلسل، لذا اقرأوا كل سؤال بعناية. تذكروا أن كل وحدة تعتمد على ما قبلها؛ الفهم الجيد للمتطلبات يؤدي إلى رسم ER دقيق، والذي بدوره يتحول إلى قاعدة بيانات علائقية خالية من الأخطاء. خذوا قسطاً من الراحة، وركزوا على فهم الروابط بدلاً من الحفظ. بالتوفيق في امتحانكم غداً، أنا واثق من قدراتكم!

خزنة الامتحان | النقاط الحرجة

28 نقطة حرجة
⚠️ فخ M6
الخلط بين الفئة الفرعية المشتركة (Shared Subclass) والفئة (Category). تذكر: المشتركة تعني التقاطع (يجب أن يكون الكيان في جميع الفئات العليا)، بينما الفئة تعني الاتحاد (يكفي أن يكون في فئة عليا واحدة).
💡 سر الامتحان M5
خصائص العلاقات في 1:N ليست ضرورية على العلاقة نفسها. يمكنك دائماً نقلها إلى الكيان في جهة N، لأن كل كيان في جهة N يشارك مرة واحدة فقط، فالقيمة تخصه هو.
⚠️ فخ M3
الاعتقاد بأن المفتاح الأجنبي (Foreign Key) لا يمكن أن يكون NULL. الحقيقة: يمكن أن يكون NULL (إلا إذا كان جزءاً من المفتاح الأساسي لجدوله أو تم وضع قيد NOT NULL عليه صراحة).
⚠️ فخ M2
الخلط بين المخطط (Schema) والحالة (State). تذكر: المخطط هو الهيكل الثابت (Intension)، بينما الحالة هي البيانات المتغيرة (Extension).
💡 سر الامتحان M3
كل مفتاح (Key) هو مفتاح فائق (Superkey)، ولكن العكس غير صحيح! المفتاح الفائق قد يحتوي على صفات إضافية لا حاجة لها للتفرد، بينما المفتاح يجب أن يكون 'أصغرياً' (Minimal).
🔑 مفهوم أساسي M5
التخصيص (Specialization) والتعميم (Generalization) هما وجهان لعملة واحدة. النتيجة الهيكلية في المخطط متطابقة تماماً، الفرق الوحيد هو في طريقة تفكيرك أثناء التصميم (من أعلى لأسفل أم العكس).
⚠️ فخ M2
الاعتقاد بأن DDL و DML لغتان منفصلتان تماماً في الواقع. في الأنظمة التجارية مثل SQL، هما مدمجتان في لغة واحدة شاملة.
⚠️ فخ M5
الاعتقاد بأن العلاقة الثلاثية (Ternary) يمكن دائماً استبدالها بثلاث علاقات ثنائية. هذا خطأ فادح؛ العلاقة الثلاثية تحفظ 'التركيبة' المحددة للثلاثة معاً، وهو ما يضيع عند تفكيكها.
⚠️ فخ M1
الاعتقاد بأن استخدام DBMS هو الحل الأمثل دائماً. في الأنظمة ذات متطلبات الوقت الفعلي الصارمة (Stringent real-time)، العبء الإضافي (Overhead) لـ DBMS يجعله خياراً سيئاً.
🔑 مفهوم أساسي M3
الفرق بين تكامل الكيان والتكامل المرجعي: تكامل الكيان يحمي الجدول نفسه (المفتاح الأساسي لا يمكن أن يكون NULL). التكامل المرجعي يحمي العلاقات بين الجداول (المفتاح الأجنبي يجب أن يكون موجوداً أو NULL).
🔑 مفهوم أساسي M6
في تحويل العلاقات، علاقات 1:1 و 1:N يمكن حلها باستخدام المفاتيح الأجنبية (Foreign Keys) داخل الجداول الموجودة. لكن علاقات M:N تتطلب دائماً إنشاء جدول جديد (Relationship relation).
💡 سر الامتحان M6
التعميم (Generalization) يكون عادةً كلياً (Total Completeness) لأن الفئة العليا تُستنتج وتُبنى أساساً من الفئات الفرعية الموجودة مسبقاً.
🔑 مفهوم أساسي M5
علاقة IS-A تعني أن الكيان في الفئة الفرعية هو *نفس الكيان المادي* الموجود في الفئة العليا. لا يتم إنشاء كيانين منفصلين، بل هو كيان واحد يلعب دوراً إضافياً.
🔑 مفهوم أساسي M2
معمارية المخططات الثلاثة (Three-Schema Architecture) هي الأساس النظري لفصل واجهة المستخدم (الخارجي) عن المنطق (المفاهيمي) عن التخزين (الداخلي).
🔑 مفهوم أساسي M4
السمة المفتاحية يمكن أن تكون مركبة! ليس بالضرورة أن تكون حقلاً واحداً. مثلاً، رقم لوحة السيارة يتكون من (الرقم، الولاية) معاً كمفتاح واحد.
💡 سر الامتحان M1
قد تعتقد أن المبرمجين هم أكثر من يستخدم قواعد البيانات، لكن في الواقع، المستخدمون السذج (Naïve end-users) مثل موظفي البنوك يشكلون الشريحة الأكبر من المستخدمين.
🔑 مفهوم أساسي M1
استقلالية البرامج عن البيانات (Program-data independence) تعني أنك تستطيع تغيير نوع القرص الصلب أو طريقة تخزين البيانات دون الحاجة لإعادة كتابة كود التطبيق.
⚠️ فخ M6
عند تحويل الكيان الضعيف، لا تنسَ أن مفتاحه الأساسي ليس المفتاح الجزئي فقط! بل هو مزيج (Combination) من المفتاح الأساسي للكيان المالك والمفتاح الجزئي للكيان الضعيف.
🔑 مفهوم أساسي M1
البيانات الوصفية (Meta-data) هي ما يجعل قاعدة البيانات 'تصف نفسها بنفسها' (Self-describing)، وهي ميزة جوهرية تفصل قواعد البيانات عن أنظمة الملفات التقليدية.
⚠️ فخ M4
نسيان تحديد 'أسماء الأدوار' (Role Names) في العلاقات العودية. بدونها، لا يمكن معرفة اتجاه العلاقة (من هو المشرف ومن هو الخاضع للإشراف).
💡 سر الامتحان M4
أثناء تحسين التصميم المبدئي، أي سمة تشير إلى كيان آخر (مثل 'رقم القسم' داخل كيان 'الموظف') يجب إزالتها كسمة وتحويلها إلى 'علاقة' (Relationship) صريحة.
⚠️ فخ M4
الخلط بين 'نوع الكيان' (Entity Type) و'مجموعة الكيانات' (Entity Set). تذكر: النوع هو الهيكل (المستطيل في المخطط)، والمجموعة هي البيانات الفعلية المخزنة في لحظة معينة.
⚠️ فخ M3
الاعتقاد بأن الصفوف (Tuples) مرتبة داخل الجدول. تذكر: العلاقة هي 'مجموعة' (Set) رياضية، والمجموعات لا ترتيب لها. لا تعتمد أبداً على ترتيب البيانات دون استخدام ORDER BY.
⚠️ فخ M1
الخلط بين DBMS و Database System. تذكر: DBMS هو البرنامج فقط (مثل MySQL)، بينما Database System هو البرنامج + البيانات المخزنة.
🔑 مفهوم أساسي M4
الكيان الضعيف لا يمكن أن يوجد بمفرده. يجب أن يرتبط بكيان مالك من خلال 'علاقة تعريف' (Identifying Relationship)، ويُعرف باستخدام المفتاح الأساسي للمالك بالإضافة إلى 'المفتاح الجزئي' الخاص به.
⚠️ فخ M5
الخلط بين أماكن وضع التعددية (Multiplicities) في ER و UML. تذكر: في ER نضع الرقم بجوار الكيان نفسه، أما في UML فنضعه في الطرف المعاكس للخط!
🔑 مفهوم أساسي M2
المعمارية ثلاثية الطبقات (3-tier) تضيف خادم تطبيقات لتعزيز الأمان وإدارة منطق الأعمال، مما يمنع العميل من الوصول المباشر لقاعدة البيانات.
💡 سر الامتحان M2
الاستقلالية المنطقية للبيانات أصعب بكثير من الاستقلالية المادية. تغيير الهيكل المنطقي غالباً ما يكسر التطبيقات، بينما تغيير التخزين المادي (مثل الفهارس) يمر دون أن تلاحظه التطبيقات.