IS211 — ER Model & Mapping

01

Entities & Attributes

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

🏢 Entity يعني إيه؟

الـ Entity هو أي شيء أو كيان موجود في الـ mini-world وعايز تخزّن بياناته في قاعدة البيانات. فكّر فيه زي الـ "اسم" في جملة — حاجة ليها وجود مستقل.

👤

EMPLOYEE

موظف محدد في الشركة

🏢

DEPARTMENT

قسم محدد في الشركة

📋

PROJECT

مشروع محدد في الشركة

🏷️ Attribute يعني إيه؟

الـ Attributes هي الصفات أو الخصائص اللي بتوصف الـ Entity. زي ما الشخص ليه اسم وعنوان وعمر — كل entity ليه attributes بتوصفه.

EXAMPLE — EMPLOYEE entity instance

Name       = 'Ragab Ahmed'         ← composite attribute
SSN        = '123456789'           ← key attribute
Address    = '731 Faisal, Giza'    ← simple attribute
Gender     = 'Male'                ← simple attribute
BirthDate  = 'April 1, 1990'      ← stored attribute
Age        = 34                    ← derived from BirthDate

📌 Default Attribute: بشكل افتراضي أي attribute هو Stored + Single-valued + Simple (Atomic). لو مختلف بتوضح ده في الـ ERD.

02

أنواع الـ Attributes

كل نوع ليه رمز معين في الـ ERD — لازم تحفظهم

⚫ Simple (Atomic) Attribute

مش ممكن يتقسم لأجزاء أصغر. ده الـ default.

Examples

SSN    = '123456789'   ← can't split further
Gender = 'Male'
Salary = 12000

ERD Shape: Oval عادي بسيط

🔘🔘 Composite Attribute

بينقسم لأجزاء أصغر ذات معنى. كل جزء ممكن يتخزن لوحده.

Examples

Name(FName, MInit, LName)
Address(Street, City, State, Zip)
Registration(Number, State)  ← composite key!

⚠️ مهم جداً: لما بتعمل Relational Table — الـ composite attribute نفسه مش بيتخزن. بس أجزاءه البسيطة هي اللي بتتخزن!

① Single-Valued Attribute

بياخد قيمة واحدة بس لكل entity. ده الـ default.

Examples

Age   = 34        ← one value per person
SSN   = '123...'   ← one SSN per employee

{} Multi-Valued Attribute

ممكن يبقى ليه أكتر من قيمة لنفس الـ entity.

Examples

{Locations}  = ['Cairo', 'Alex', 'Giza']
{Hobbies}    = ['Chess', 'Swimming']
{PhoneNums}  = ['010...', '011...']

ERD Shape: Double Oval (أوفال مزدوج) — وبتكتبه {Attr}

⟳ Derived Attribute

بيتحسب من attribute تاني — مش بنخزنه في قاعدة البيانات.

Examples

Age             ← derived from BirthDate
Num_Employees   ← derived from counting employees
TotalSalary     ← derived from summing salaries

ERD Shape: Dashed Oval (أوفال بخط منقط) — مش بنخزنه في الـ table!

🔑 Key Attribute

بيحدد كل entity بشكل فريد — لازم يكون Unique ومش NULL.

Examples

SSN         ← key of EMPLOYEE
DNumber     ← key of DEPARTMENT
VehicleId   ← key of CAR
Registration(Number,State) ← composite key of CAR

ERD Shape: Oval بـ underline تحت اسمه — Unique + NOT NULL

📐 ERD Attribute Shapes — مرجع بصري سريع

03

Key Attributes — التعريف والفرق

الفرق بين Key و Unique و Candidate Key

🔑 Key vs. Unique — الفرق المهم!

Property	Key Attribute	Unique Constraint
Unique Values?	✅ Yes	✅ Yes
Allows NULL?	❌ No (NOT NULL)	⚠️ Yes (NULLs allowed & repeated)
Can be PK?	✅ Yes	❌ No

💡 Candidate Keys: entity ممكن يبقى عنده أكتر من key واحد — كل دول بيتسموا Candidate Keys. بتختار واحد منهم يبقى الـ Primary Key.

CAR — Two Candidate Keys

-- Candidate Key 1:
Vehicle_Id = 'TK629'

-- Candidate Key 2 (composite!):
Registration(Number='ABC 123', State='TX')

-- Pick ONE as Primary Key

🚨 Exam Trap — Choosing the Wrong Key! الـ Book Title مش key جيد لكتاب فيزيقي — ممكن يبقى في أكتر من نسخة من "Gone with the Wind". الـ key الصح هو serial number فريد لكل نسخة مطبوعة.

04

ERD Notation — الرموز والأشكال

اللغة البصرية للـ Entity-Relationship Diagrams

📐 ملخص كل الأشكال

Rectangle

Strong Entity Type

Double Rectangle

Weak Entity Type

Diamond

Relationship Type

Double Diamond

Identifying Relationship

Oval

Simple Attribute

Underlined Oval

Key Attribute

Double Oval

Multi-valued Attribute

Dashed Oval

Derived Attribute

Double Line

Total Participation (Mandatory)

Single Line

Partial Participation (Optional)

1 and N labels

Cardinality Ratio 1:N

Dashed Underline

Partial Key (Weak Entity)

05

Relationships & Relationship Types

الروابط بين الـ Entities — الـ "أفعال" في الـ ERD

🔗 ما هو الـ Relationship؟

الـ Relationship هو الرابط الذي يربط entities اتنين أو أكتر بمعنى محدد. مثلاً: EMPLOYEE "WORKS_FOR" DEPARTMENT — ده relationship.

💡 مهم: نفس الـ entities ممكن يكون بينهم أكتر من relationship — بس كل واحد له معنى مختلف. مثلاً: EMPLOYEE-DEPARTMENT لهم WORKS_FOR وكمان MANAGES — كل واحد بيعبر عن حاجة مختلفة!

📊 Degree of a Relationship — درجة العلاقة

الـ Degree هو عدد الـ entity types المشاركة في الـ relationship.

Unary (Degree 1)

Entity يرتبط بنفسه — recursive relationship

EMPLOYEE SUPERVISION EMPLOYEE
(supervisor / supervisee)

Binary (Degree 2)

الأكثر شيوعاً — entity اتنين مع بعض

EMPLOYEE WORKS_ON PROJECT
EMPLOYEE WORKS_FOR DEPARTMENT

Ternary (Degree 3)

ثلاث entities مع بعض في نفس الوقت

SUPPLIER SUPPLY PROJECT
       + PART (+ Quantity)

📎 Relationship Attributes — الـ Relationship نفسه ممكن يبقى ليه Attributes!

Example — WORKS_ON with attribute Hours

EMPLOYEE -- [ WORKS_ON ] -- PROJECT
               |
            Hours   ← عدد الساعات اللي الموظف بيشتغلها في المشروع ده

-- قيمة Hours بتعتمد على الاتنين: (employee, project)
-- Ahmed يشتغل 20 ساعة أسبوعياً على Project-X
-- Ahmed يشتغل 15 ساعة أسبوعياً على Project-Y

-- بنفس المنطق: MANAGES له Start_Date كـ attribute

📌 Rule: الـ Relationship Attributes الأكثر شيوعاً في علاقات M:N. في علاقات 1:N ممكن تنقلها للـ entity في الـ N-side.

06

Cardinality Ratios — نسب العلاقة

الحد الأقصى لعدد العلاقات — مهم جداً في الامتحانات!

🔢 الأنواع الثلاثة للـ Cardinality

📐 Cardinality Visual — كل نوع بالتوضيح

🚨 أهم Trap في الامتحانات — فكر من الاتجاهين!
"Person بيحب Ice Cream Flavors كتير" → هتقول 1:M ؟ لكن تفكّر: "كتير من الناس بيحبوا نفس الطعم!" → الصواب هو M:N!
دايماً اسأل من الاتجاهين الاتنين قبل ما تحدد الـ Cardinality.

07

Participation Constraints — الـ Minimum

Total vs. Partial — Mandatory vs. Optional

══ Total Participation (Mandatory)

كل entity instance لازم يكون موجود في الـ relationship. مش مسموح يكون entity بدون علاقة.

Double Line = Total/Mandatory

مثال: كل EMPLOYEE لازم يـ WORKS_FOR قسم — ما فيش موظف بدون قسم!

─ Partial Participation (Optional)

بعض entity instances ممكن ما يكونوش في الـ relationship. مسموح entity يكون بدون علاقة.

Single Line = Partial/Optional

مثال: مش كل EMPLOYEE بيـ MANAGES قسم — معظم الموظفين مش مديرين!

🔍 نتائج الـ Join وعلاقتها بالـ Participation — من الامتحانات!

نتيجة الـ Natural Join	المعنى
النتيجة = 0 records	الـ Relationship Optional من الجانبين (Partial/Partial)
النتيجة ≥ Min(\|T1\|, \|T2\|)	على الأقل جانب واحد Total (Mandatory)
النتيجة دايماً ≥ \|T2\|	T2 لديها Total Participation — كل record في T2 ليه match
النتيجة = \|T1\| × \|T2\|	Cross Join behavior — M:N وكل entity بترتبط بكل حاجة

Exam Example — Final 2024

-- |T1| = 100, |T2| = 100
-- Natural Join نتيجته 10,000 = 100 × 100
-- → Cross Join behavior → الـ Relationship Optional على الجانبين (M:N)

-- "never less than 100 records"
-- → On at least one side the participation is Total (Mandatory)

08

Weak Entities — الـ Entity الضعيفة

entity مش قادرة تتعرف عن نفسها لوحدها

⚠️ ما هو الـ Weak Entity؟

الـ Weak Entity هو entity مالوش Key attribute خاص بيه. بيحتاج entity تاني (الـ Owner) عشان يتعرف.

مثال: DEPENDENT
عندنا اتنين بنات اسمهم "سارة" في قاعدة البيانات:
• سارة بنت أحمد (SSN: 123)
• سارة بنت محمد (SSN: 456)

الاسم "سارة" وحده مش كافي — محتاجين SSN الأب عشان نفرقهم!

Double Rectangle → الـ Weak Entity
Double Diamond → الـ Identifying Relationship
Partial Key → بيتبين بـ dashed underline
Full ID = Owner's PK + Partial Key
Total Participation → دايماً لازم يكون معاه Owner

📐 DEPENDENT Weak Entity — الـ ERD

🚨 Exam Trap من Final 2023: "A weak entity is an entity with only one column which is the primary key of the strong entity" → FALSE!
الـ Weak Entity ليه Attributes خاصة بيه زي (Name, Sex, BirthDate). الفرق إنه مش عنده Key كافي لوحده — بيحتاج Owner's PK + Partial Key لتحديد الـ record.

09

Min/Max Notation — الطريقة البديلة

بدل 1:N نقول (min, max) على كل جانب

📊 الفرق بين (min, max) Notation والعادي

📌 (min, max) Rules:
• min = 0 → Optional (Partial)
• min ≥ 1 → Mandatory (Total)
• max = 1 → يرتبط بـ entity واحدة كحد أقصى
• max = N → يرتبط بـ entities كتير

Company ERD — Min/Max Notation

EMPLOYEE (0,1) ──[MANAGES]── (1,1) DEPARTMENT
موظف ممكن يدير 0 أو 1 قسم
القسم لازم يبقى ليه مدير واحد بالظبط

EMPLOYEE (1,1) ──[WORKS_FOR]── (1,N) DEPARTMENT
موظف يشتغل في قسم واحد بالظبط
القسم ممكن يبقى فيه موظف واحد أو أكتر

10

Company ERD الكامل

المثال المرجعي للمنهج كله — ادرسه كويس!

🏗️ مكونات الـ Company Database

Entity	Attributes	Key
EMPLOYEE	Name(Fname, Minit, Lname), Ssn, Bdate, Address, Sex, Salary	Ssn
DEPARTMENT	Dname, Dnumber, {Locations}, Num_Employees(derived)	Dnumber
PROJECT	Pname, Pnumber, Plocation	Pnumber
DEPENDENT (Weak)	Dep_Name(partial), Sex, BDate, Relationship	Essn + Dep_Name

Relationship	بين	Cardinality	Participation	Attributes
WORKS_FOR	EMPLOYEE — DEPARTMENT	N:1	Employee: Total \| Dept: Partial	—
MANAGES	EMPLOYEE — DEPARTMENT	1:1	Employee: Partial \| Dept: Total	Start_Date
CONTROLS	DEPARTMENT — PROJECT	1:N	Project: Total	—
WORKS_ON	EMPLOYEE — PROJECT	M:N	Both: Total	Hours
SUPERVISION	EMPLOYEE — EMPLOYEE	1:N (recursive)	Both: Partial	—
DEPENDENTS_OF	EMPLOYEE — DEPENDENT	1:N (identifying)	Dependent: Total	—

📐 Company ERD — Full Diagram

11

Design Tips & Common Mistakes

أكتر الأخطاء الشائعة في التصميم — من المحاضرة مباشرة

❌ غلط: تعمل Entity لحاجة بسيطة

EMPLOYEE makes → SALARY (Entity). الـ Salary مش محتاج حياة مستقلة.

✅ صح: خلّيها Attribute

EMPLOYEE (Salary). لو الحاجة مش محتاجة Relationships أو Properties — خلّيها Attribute.

❌ غلط: FK في الـ Conceptual Model

EMPLOYEE (deptno) works_for DEPT(deptno). الـ deptno في الـ Employee هو FK وده concept رلائشنال مش ERD.

✅ صح: استخدم Relationships

الـ WORKS_FOR relationship بيعبر عن الارتباط — مش محتاج تضيف FK attribute في الـ ERD.

❌ غلط: 1:M بدل M:N

"Person يحب Ice Cream Flavors كتير" → مش 1:M. فكّر: كتير من الناس بيحبوا نفس الطعم → M:N!

✅ صح: فكّر من الاتجاهين

اسأل "كم entity في الجانب الآخر يمكن يرتبط بـ entity واحدة هنا؟" — الاتجاهين الاتنين!

❌ غلط: Attributes معقدة

EMPLOYEE (assignments: projname, role, hrs). ده معقد جداً كـ attribute.

✅ صح: خلّيها Entity + Relationship

WORKS_ON relationship مع Hours attribute — أو ASSIGNMENT entity لو محتاجين تفاصيل أكتر.

🎯

Quiz 1 — ER Model Concepts

أسئلة حقيقية من امتحانات 2023 و2024 و2025 — اختبر نفسك!

Q1 Final 2023

A weak entity is an entity with only one column which is the primary key of the strong entity.

✅ FALSE! الـ Weak Entity ليها attributes خاصة بيها زي (Name, Sex, BirthDate). الفرق إنها مش عندها Key كافي لوحدها — بتحتاج Owner's PK + Partial Key عشان تتعرف. مش بس column واحد!

Q2 Final 2023

The degree of a relationship type is the number of participating...

✅ الـ Degree of a Relationship = عدد الـ Entity Types المشاركة. Binary = 2 entity types. Ternary = 3 entity types. مش عدد الـ attributes أو الـ relationships.

Q3 Final 2023 / 2024

Based on the ERD for EMPLOYEE and PROJECT (M:N WORKS_ON relationship, Total participation for both), which relation would be INCORRECT in the relational mapping?

✅ Exam(ExamID, NID, ExamName) غلط! العلاقة بين Person وExam هي M:N (Qualification). في M:N مش بتحط FK في أي من الـ entities مباشرة — لازم junction table هي Qualification(NID, ExamID, QualifiedDate). لو حطيت NID في Exam معناه إنك عملتها 1:N وده غلط!

Q4 Final 2023

Consider a university database. Which of the following is a WRONG answer regarding "each session is held in a room"?

✅ الإجابة الغلط هي C: "The relationship from course to room is 1:M". Course مش بترتبط مباشرة بـ Room — الـ Session هي اللي بتتحمل فيها Room. Course → Session (1:M) وSession → Room (M:1).

Q5 Final 2023

Which of the following entities shows a one-to-many RECURSIVE relation? (Given: paper_reference(paper_id, conference_occurrence_year, reference_paper_id, reference_paper_conference_occurrence_year))

✅ paper_reference بتربط paper بـ paper تانية — ده recursive (self-referencing) relationship. الـ paper بترجع لـ paper تانية كمرجع. paper_id → reference_paper_id كلاهما من نفس الـ paper entity.

Q6 Final 2024

The relationship "Written-By" between Book and Author is:

✅ Written-By هي M:N — كتاب واحد ممكن يتكتب بواسطة مؤلفين كتير، ومؤلف واحد ممكن يكتب كتب كتير. فكّر من الاتجاهين!

Q7 Final 2024

The relationship "Stocks" between Warehouse and Book is:

✅ Stocks بين Warehouse وBook هي M:N — warehouse واحد بيخزن كتب كتير، ونفس الكتاب ممكن يكون متخزن في أكتر من warehouse.

Q8 Final 2024

The min and max cardinality of Entity type "Shopping-Basket" at Basket-of relationship is:

✅ "Customer can have only one shopping basket at a time" → كل basket لازم يبقى تابع لـ customer واحد بالظبط (1,1). الـ basket لازم يكون ليه صاحب (min=1) وما ينفعش يبقى لأكتر من customer (max=1).

Q9 Final 2025

More than one candidate key can be used during the conceptual design of the databases for the same entity:

✅ TRUE! Entity ممكن يبقى عنده أكتر من Candidate Key. مثلاً CAR عنده Vehicle_Id وRegistration(Number,State) كلاهما candidate keys. هتختار واحد منهم يبقى Primary Key.

Q10 Final 2025

Not all entities have clear primary key during the conceptual model:

✅ TRUE! الـ Weak Entities مش عندها Primary Key واضح — بتحتاج Owner's PK + Partial Key. ده بالظبط اللي بيخليها "Weak".

12

ER→Relational Mapping — المقدمة

7 خطوات منظمة لتحويل الـ ERD لـ Tables حقيقية

🗺️ الـ Golden Rules قبل ما تبدأ

📌 القواعد الذهبية:
1. كل Entity → جدول جديد
2. علاقات 1:1 و1:N → Foreign Key في جدول موجود
3. علاقات M:N → جدول جديد
4. الـ Multivalued Attribute → جدول جديد
5. الـ Derived Attribute → مش بيتخزن خالص

Step	بيتعامل مع	الناتج
1	Strong Entity	جدول جديد
2	Weak Entity	جدول + FK من Owner
3	Binary 1:1	FK في الـ total participation side
4	Binary 1:N	FK في الـ N-side
5	Binary M:N	جدول جديد + 2 FKs
6	Multivalued Attr	جدول جديد + FK
7	N-ary Relationship	جدول جديد + N FKs

13

Step 1: Strong Entity Types

أبسط خطوة — كل strong entity يبقى جدول

1

Mapping of Regular (Strong) Entity Types

لكل Strong Entity في الـ ERD، بنعمل جدول (Relation) يشمل:

كل الـ Simple Attributes مباشرة
الـ Composite Attribute → بنحط أجزاءه البسيطة بس (مش الـ composite نفسه!)
الـ Derived Attributes → مش بنخزنهم!
الـ {Multivalued Attributes} → هنتعامل معاهم في Step 6
بنختار واحد من الـ Key Attributes كـ Primary Key

Example — Company Database Step 1

-- EMPLOYEE entity: Name(Fname,Minit,Lname) composite → break into parts
EMPLOYEE (Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary)
           ↑ PK    ↑ composite Name broken into 3 parts
-- NOT included: Age (derived), Name itself (composite)

DEPARTMENT (Dnumber, Dname)
           ↑ PK
-- NOT included: Locations (multivalued→Step 6), Num_Employees (derived)

PROJECT (Pnumber, Pname, Plocation)

🚨 أهم Exam Trap في Step 1: الـ Composite Attribute (Name) مش بيتخزن كـ column — بنحط أجزاءه بس (Fname, Minit, Lname). لو السؤال سألك "where is Name?" الإجابة: اتعوّض بالـ 3 components بتاعها!

14

Step 2: Weak Entity Types

بياخد مفتاح صاحبه كـ FK

2

Mapping of Weak Entity Types

لكل Weak Entity W بصاحب E، بنعمل جدول يشمل:

كل الـ Simple Attributes بتاعة W
الـ Primary Key بتاع الـ Owner Entity كـ Foreign Key
الـ Primary Key للجدول الجديد = Owner's PK + Partial Key

Example — DEPENDENT Weak Entity

DEPENDENT (Essn, Dependent_Name, Sex, Bdate, Relationship)
            ↑ FK → EMPLOYEE.Ssn    ↑ Partial Key
            ↑──── Combined PK ─────↑

-- Sara w/ Essn=123 ≠ Sara w/ Essn=456 (different employees!)
-- FK with CASCADE DELETE → لو الموظف اتحذف، dependents بتتحذف معاه

15

Step 3: Binary 1:1 Relationships

الـ FK بيروح للـ Total Participation side

3

Mapping of Binary 1:1 Relationship Types

بنختار من الـ entities اللي بتشارك في الـ 1:1 — الأفضل نختار الـ entity اللي عندها Total Participation — وبنضيف:

الـ Primary Key بتاع الـ entity التانية كـ Foreign Key
أي Relationship Attributes بتاعة الـ 1:1 relationship

Example — MANAGES (1:1) relationship

-- DEPARTMENT has TOTAL participation in MANAGES
-- (كل قسم لازم يبقى ليه مدير)
-- So FK goes into DEPARTMENT table

DEPARTMENT (Dnumber, Dname, Mgr_Ssn, Mgr_Start_Date)
                              ↑ FK → EMPLOYEE.Ssn
                                      ↑ Relationship attribute of MANAGES

💡 ليه DEPARTMENT ومش EMPLOYEE؟ لو حطيت الـ FK في EMPLOYEE، معظم الموظفين مش مديرين → هيبقى في الـ Mgr_Ssn column قيمة NULL لكل الموظفين العاديين. أحسن نحط FK في DEPARTMENT عشان كل قسم لازم يبقى ليه مدير (Total participation).

16

Step 4: Binary 1:N Relationships

الـ FK بيروح للـ N-side دايماً

4

Mapping of Binary 1:N Relationship Types

أسهل rule في الـ mapping: الـ FK بيروح للـ entity اللي على الـ N-side دايماً.

Example — Company Database 1:N Relationships

-- WORKS_FOR (N:1) — Employee → Department
-- EMPLOYEE is on N-side → FK goes into EMPLOYEE
EMPLOYEE (Ssn, ..., Super_Ssn, Dno)
                         ↑ FK → EMPLOYEE.Ssn (SUPERVISION recursive!)
                                  ↑ FK → DEPARTMENT.Dnumber (WORKS_FOR)

-- CONTROLS (1:N) — Department controls Projects
-- PROJECT is on N-side → FK goes into PROJECT
PROJECT (Pnumber, Pname, Plocation, Dnum)
                                          ↑ FK → DEPARTMENT.Dnumber

💡 ملحوظة مهمة — Recursive Relationship: الـ SUPERVISION هي 1:N recursive. الـ FK بيجي في نفس الجدول (EMPLOYEE) ويرفر لنفس الـ Primary Key (Ssn) في نفس الجدول. الـ Supervisor هو employee كمان!

17

Step 5: Binary M:N Relationships

لازم جدول جديد — مفيش FK مباشر!

5

Mapping of Binary M:N Relationship Types

علاقات M:N مينفعش نحط FK في أي من الجدولين — لازم جدول جديد (Junction Table):

الجدول الجديد بيشمل الـ Primary Keys لكل الجدولين كـ Foreign Keys
الـ Primary Key بتاع الجدول الجديد = (FK1 + FK2) composite
أي Relationship Attributes بتتضاف هنا

Example — WORKS_ON (M:N) relationship

-- Can't put FK in EMPLOYEE (one employee → many projects)
-- Can't put FK in PROJECT  (one project → many employees)
-- Solution: Create WORKS_ON junction table!

WORKS_ON (Essn, Pno, Hours)
          ↑ FK → EMPLOYEE.Ssn
                  ↑ FK → PROJECT.Pnumber
          ↑─────── Composite PK ─────↑
                                     ↑ Relationship Attribute

📐 M:N Mapping — Before & After

🚨 أهم Exam Trap في Step 5 — من امتحانات 2023 و2024 و2025:
في علاقة M:N بين Person وExam — الإجابة الغلط هي Exam(ExamID, NID, ExamName) — لأنك حطيت الـ FK مباشرة في الـ Exam table، وده بيعمل 1:N مش M:N!
الصح هو جدول جديد: Qualification(NID, ExamID, QualifiedDate)

18

Step 6: Multivalued Attributes

كل {Multivalued} بيبقى جدول جديد

6

Mapping of Multivalued Attributes

الـ Multivalued Attributes مش ممكن تتخزن في column واحد — لازم جدول جديد:

Example — DEPARTMENT has {Locations}

-- {Locations} is multivalued → Create DEPT_LOCATIONS table

DEPT_LOCATIONS (Dnumber, Dlocation)
                ↑ FK → DEPARTMENT.Dnumber
                ↑────── Composite PK ───↑

-- Data example:
-- (5, 'Houston'), (5, 'Bellaire'), (5, 'Sugarland') — all for Dept 5
-- (4, 'Stafford')  — for Dept 4

19

Step 7: N-ary Relationship Types

ثلاث entities أو أكتر → جدول جديد

7

Mapping of N-ary Relationship Types

نفس منطق M:N بس بنوسّعه لـ N entities:

Example 1 — SUPPLY (Ternary: Supplier × Project × Part)

SUPPLY (Sname, Proj_name, Part_no, Quantity)
        ↑ FK→SUPPLIER  ↑ FK→PROJECT  ↑ FK→PART
        ↑──────────── Composite PK (all 3) ─────↑

Example 2 — ENROLLED (Student × Course × Semester)

ENROLLED (StudId, CourseId, SemId, Grade)
          ↑─────── Composite PK (all 3 FKs) ────↑

20

الـ Schema الكاملة — Company Database

نتيجة تطبيق الـ 7 خطوات على الـ Company ERD

🗄️ Final Relational Schema

Complete Company Relational Schema

-- Step 1: Strong Entities
EMPLOYEE       (Ssn, Fname, Minit, Lname, Bdate, Address, Sex, Salary, Super_Ssn, Dno)
DEPARTMENT     (Dnumber, Dname, Mgr_Ssn, Mgr_Start_Date)
PROJECT        (Pnumber, Pname, Plocation, Dnum)

-- Step 2: Weak Entity
DEPENDENT      (Essn, Dependent_Name, Sex, Bdate, Relationship)

-- Step 3: 1:1 → FK in DEPARTMENT (total participation)
           Mgr_Ssn + Mgr_Start_Date already in DEPARTMENT above

-- Step 4: 1:N → FKs on N-side
           Super_Ssn in EMPLOYEE (SUPERVISION recursive)
           Dno in EMPLOYEE (WORKS_FOR)
           Dnum in PROJECT (CONTROLS)

-- Step 5: M:N → New junction table
WORKS_ON       (Essn, Pno, Hours)

-- Step 6: Multivalued attribute
DEPT_LOCATIONS (Dnumber, Dlocation)

────────────────────────────────────────────
-- Foreign Key References:
   EMPLOYEE.Super_Ssn → EMPLOYEE.Ssn
   EMPLOYEE.Dno → DEPARTMENT.Dnumber
   DEPARTMENT.Mgr_Ssn → EMPLOYEE.Ssn
   PROJECT.Dnum → DEPARTMENT.Dnumber
   WORKS_ON.Essn → EMPLOYEE.Ssn
   WORKS_ON.Pno → PROJECT.Pnumber
   DEPENDENT.Essn → EMPLOYEE.Ssn
   DEPT_LOCATIONS.Dnumber → DEPARTMENT.Dnumber

21

Summary Table — ER ↔ Relational

المقارنة الكاملة بين الـ ER Model والـ Relational Model

📊 Correspondence Table

ER MODEL	RELATIONAL MODEL	جدول جديد؟	الـ PK
Strong Entity Type	Entity Relation	✅ Yes	Key Attribute
Weak Entity Type	Entity Relation + FK from Owner	✅ Yes	Owner PK + Partial Key
1:1 Relationship	FK (في الـ total side)	❌ No	—
1:N Relationship	FK (في الـ N-side)	❌ No	—
M:N Relationship	Junction Table + 2 FKs	✅ Yes	(FK1, FK2)
{Multivalued Attr}	New Table + FK to owner	✅ Yes	(Attr, FK)
N-ary Relationship	New Table + N FKs	✅ Yes	All N FKs
Simple Attribute	Column	❌ No	—
Composite Attribute	مكوناته البسيطة فقط	❌ No	—
Derived Attribute	مش بيتخزن	❌ No	—

🗂️

Quiz 2 — ER to Relational Mapping

أسئلة من امتحانات 2023 و2024 و2025 على الـ Mapping — الأصعب!

Q1 Final 2024

Mapping entity "Warehouse" to Relational Schema is: (Warehouse has: code, phone, address. Stocks relationship to Book has attribute: number)

✅ Warehouse → Strong Entity → Table with its own attributes only. الـ "Stocks" relationship هي M:N بين Warehouse وBook، فمش بنحط ISBN في Warehouse مباشرة — هيبقى في junction table. الـ Warehouse table بس بياخد attributes بتاعته: code, phone, address.

Q2 Final 2024

Mapping relationship "Basket-Of" (1:1 between Customer and Shopping-Basket) to Relational Schema is:

✅ Basket-Of هي 1:1. في 1:1 بنختار الـ entity اللي عندها Total Participation. Customer can have only ONE basket = (1,1) → Customer has total participation. فبنضيف BasketID كـ FK في Customer. الـ Customer table بيشمل: (email, name, address, phone, BasketID).

Q3 Final 2024

Mapping relationship "Contains" (M:N between Book and Shopping-Basket, with attribute: number) to Relational Schema is:

✅ Contains هي M:N بين Book وShopping-Basket. في M:N → جدول جديد! الجدول الجديد بياخد: ISBN (FK→Book) + basketID (FK→ShoppingBasket) + number (Relationship Attribute). الـ PK = (ISBN, basketID) combined.

Q4 Final 2024

After mapping relationship "Written-By" (M:N between Book and Author) to Relational Schema, the number of attributes forming the primary key for the mapped relation is:

✅ Written-By هي M:N → Junction Table. الـ PK بيتكون من: ISBN (من Book) + author_name (من Author) = 2 attributes. كل M:N بييجي بـ Composite PK من الـ 2 FKs.

Q5 Final 2024

Entity Type "Doctors" has inheritance with subclasses Regular Doctor (SALARY) and Doctor on Call (FS_PR_CL, PYMT_DU), with overlapping 'o' symbol. The inheritance is:

✅ الرمز 'o' = Overlapping (طبيب ممكن يكون Regular وOn-Call في نفس الوقت). والـ Participation بيكون Partial لأنه ممكن يكون في طبيب مش في أي subclass. إذن: Partial + Overlapping.

Q6 Final 2024

If mapping entity type "Doctors" to relational schema is done using Single relation with multiple type attributes, the resulting relation will have how many columns? (Doctor: DOC_NO, QUALIFICATION, PH_NO, D_NAME + Regular Doctor: SALARY + Doctor on Call: FS_PR_CL, PYMT_DU)

✅ Single relation with multiple type attributes: بنحط كل الـ attributes في جدول واحد + type column لكل subtype.
Doctor: DOC_NO, QUALIFICATION, PH_NO, D_NAME (4)
Regular: SALARY (1)
On Call: FS_PR_CL, PYMT_DU (2)
Type columns: is_Regular, is_OnCall (2)
Total = 4 + 1 + 2 + 2 = 9 columns

Q7 Final 2024

Mapping relationship "Works-in" (N:1 between Doctor and Department) to Relational Schema is:

✅ Works-in هي N:1 (many doctors → one department). في 1:N الـ FK بيروح للـ N-side. الـ Doctor هو الـ N-side → بنضيف D_Name (FK→Department) في جدول Doctor. مش محتاجين جدول جديد!

Q8 Final 2025

When converting EERD into relational model, the type of participation does NOT affect which option of the 4 conversion options used:

✅ FALSE! الـ Participation Type بيأثر على الـ conversion option. مثلاً الـ "Single relation with one type attribute" بتشتغل بشكل أفضل مع الـ Disjoint subclasses. والـ Total/Partial participation بيأثر على اختيارك للطريقة الأنسب.

Q9 Final 2025

The most guaranteed normal form for a database with weak entities and many-to-many relationships is:

✅ لما بتعمل Mapping صح للـ ER Model (including weak entities و M:N as junction tables) — الناتج بيكون في الـ 2nd Normal Form على الأقل. الـ Weak Entity بـ composite PK والـ M:N Junction tables بتضمن إزالة الـ Partial Dependencies.

Q10 Final 2025

Once a database model reaches Relational Model and primary keys have not been highlighted yet, then all its relations is... NF?

✅ لو وصلنا للـ Relational Model بدون تحديد الـ Primary Keys — ده بيضمن الـ 1st Normal Form فقط. الـ 2NF و3NF بيحتاجوا تحديد الـ PKs والتحقق من الـ Functional Dependencies.

⚡

Cheat Sheet — المرجع السريع

كل حاجة مهمة في صفحة واحدة — ذاكر ده قبل الامتحان!

🔵 Attribute Types

Simple (Atomic)

مش قابل للتقسيم. Default. Oval عادي.

Composite

قابل للتقسيم لأجزاء. Tree of Ovals. في الـ Table → أجزاءه البسيطة فقط (مش هو نفسه!)

Single-valued

قيمة واحدة. Default. Oval عادي.

{Multi-valued}

أكتر من قيمة. Double Oval. في الـ Relational Model → جدول جديد (Step 6)!

Derived

بيتحسب من غيره. Dashed Oval. مش بيتخزن في الـ Table!

Key Attribute

Unique + NOT NULL. Underlined Oval. اختر واحد كـ Primary Key.

Default Attribute

Stored + Single-valued + Simple (Atomic) — لو مختلف بتوضح ده بس!

📐 ERD Shapes

Rectangle

Strong Entity

Double Rectangle

Weak Entity

Diamond ◇

Relationship Type

Double Diamond ◈

Identifying Relationship (للـ Weak Entity)

Double Line ══

Total / Mandatory Participation

Single Line ─

Partial / Optional Participation

Dashed Underline

Partial Key (في الـ Weak Entity)

🔢 Cardinality & Participation

1:1

كل entity في كل جانب يرتبط بحد أقصى entity واحدة في الجانب التاني. مثال: MANAGES.

1:N

entity واحدة ترتبط بـ entities كتير. مثال: WORKS_FOR (قسم واحد — موظفين كتير).

M:N

entities كتير ترتبط بـ entities كتير. مثال: WORKS_ON. دايماً → Junction Table!

Total = Mandatory

كل entity لازم يشارك في الـ relationship. Double Line. min ≥ 1.

Partial = Optional

بعض entities مش مضطرة تشارك. Single Line. min = 0.

(0,1)

Optional — على الأكتر علاقة واحدة. مثال: EMPLOYEE في MANAGES.

(1,1)

Mandatory — علاقة واحدة بالظبط. مثال: DEPARTMENT في MANAGES.

(1,N)

Mandatory — علاقة أو أكتر. مثال: DEPARTMENT في WORKS_FOR.

🗺️ 7 Mapping Steps — ملخص

Step 1 — Strong Entity

جدول جديد + simple attrs فقط. Composite → أجزاءه. Derived → مش بتتخزن.

Step 2 — Weak Entity

جدول جديد. PK = Owner PK (as FK) + Partial Key combined.

Step 3 — Binary 1:1

FK في الـ Total Participation side + Relationship Attributes. مش جدول جديد!

Step 4 — Binary 1:N

FK في الـ N-side + Relationship Attributes. مش جدول جديد!

Step 5 — Binary M:N

جدول جديد! PK = (FK1 + FK2) Composite. + Relationship Attributes.

Step 6 — Multivalued

جدول جديد! PK = (Attribute + FK to owner) Composite.

Step 7 — N-ary

جدول جديد! PK = كل الـ N FKs combined.

🔍 Join Results & Participation

Join result = 0

كلا الجانبين Optional (Partial على الاتنين)

Join ≥ Min(|T1|,|T2|)

على الأقل جانب واحد Total (Mandatory)

Join دايماً ≥ |T2|

T2 عندها Total Participation — كل record في T2 ليه match

Join = |T1| × |T2|

Cross Join behavior — M:N + Optional على الجانبين

🚨 Common Exam Traps — دول بييجوا كتير!

M:N FK مباشر

غلط! Exam(ExamID, NID, ExamName) → غلط لـ M:N. الصح: Qualification(NID, ExamID, QualifiedDate)

Composite في Table

Name مش بيتحط كـ column — بس Fname + Minit + Lname. الـ Composite نفسه بيختفي!

Derived في Table

Age و Num_Employees مش بيتخزنوا! بيتحسبوا وقت الحاجة.

Weak Entity Definition

غلط إن الـ Weak Entity بس column واحد هو PK الـ Strong. ليها attributes خاصة!

FK في Conceptual ERD

في الـ ERD مفيش FK attributes — بستخدم Relationships. FK ده concept relational بس!

1:M بدل M:N

فكّر من الاتجاهين! "Person likes Flavors" مش 1:M — كتير من الناس بيحبوا نفس الطعم → M:N!

Written-By Cardinality

M:N — كتاب ممكن يكون ليه مؤلفين كتير، ومؤلف واحد ممكن يكتب كتب كتير.

Participation في Mapping

الـ Participation بيأثر على اختيار الـ Mapping Option — مش صح إنه ما يأثرش!

PK Count في M:N

في M:N Junction Table → PK = 2 attributes (FK1 + FK2). مش 1 ومش 3!

Single Relation Columns

عد كل: superclass attrs + كل subclass attrs + type columns (واحد لكل subtype في overlapping)

ER Model &Relational Mapping

Entities & Attributes

أنواع الـ Attributes

Key Attributes — التعريف والفرق

ERD Notation — الرموز والأشكال

Relationships & Relationship Types

Cardinality Ratios — نسب العلاقة

Participation Constraints — الـ Minimum

Weak Entities — الـ Entity الضعيفة

Min/Max Notation — الطريقة البديلة

Company ERD الكامل

Design Tips & Common Mistakes

Quiz 1 — ER Model Concepts

ER→Relational Mapping — المقدمة

Step 1: Strong Entity Types

Step 2: Weak Entity Types

Step 3: Binary 1:1 Relationships

Step 4: Binary 1:N Relationships

Step 5: Binary M:N Relationships

Step 6: Multivalued Attributes

Step 7: N-ary Relationship Types

الـ Schema الكاملة — Company Database

Summary Table — ER ↔ Relational

Quiz 2 — ER to Relational Mapping

Cheat Sheet — المرجع السريع

🔵 Attribute Types

📐 ERD Shapes

🔢 Cardinality & Participation

🗺️ 7 Mapping Steps — ملخص

🔍 Join Results & Participation

🚨 Common Exam Traps — دول بييجوا كتير!

ER Model &
Relational Mapping