⚡ IS211 · EER Model + Normalization · All 3 Finals Covered

Database Systems
EER Model & Normalization

Chapters

Finals (2023-25)

20+

Exam Questions

Mapping Options

Enhanced Entity-Relationship (EER) Model

Subclasses · Superclasses · Specialization · Generalization · Constraints · Mapping

🏗️ Subclasses & Superclasses — الفكرة الأساسية

أحياناً الـ entity type بيكون فيه تجميعات أو أنواع فرعية ليه معنى إضافي. مثلاً:

Superclass (النوع الأب)

EMPLOYEE superclass

// EMPLOYEE entity has attributes:
Name, Ssn, Birth_date, Address

// Grouped into subclasses by JOB:
SECRETARY    → Typing_speed
TECHNICIAN   → Tgrade
ENGINEER     → Eng_type

// By MANAGEMENT role:
MANAGER      → manages PROJECT

// By PAY METHOD:
SALARIED_EMP → Salary
HOURLY_EMP   → Pay_scale

📌 القاعدة الأساسية:
• الـ Subclass بتمثل نفس الـ real-world entity بس في role مختلف
• Entity مش ممكن يكون في subclass لوحده — لازم يكون في الـ superclass الأول
• Member في الـ superclass ممكن يكون في أكتر من subclass في نفس الوقت

مثال: موظف مهندس وبياخد مرتب ثابت → في ENGINEER + SALARIED_EMPLOYEE معاً

⚠️ اصطلاحات مهمة:
Superclass = Supertype = الأب
Subclass = Subtype = الفرع
العلاقة = superclass/subclass relationship

📊 EER Diagram — EMPLOYEE Specializations

ده الـ EER diagram الأساسي اللي بيجي في الامتحانات. افهمه كويس!

🧬 Inheritance — الوراثة

الـ entity لما بيكون member في subclass، بيورّث كل حاجة من الـ superclass:

SECRETARY entity gets:

// Inherited from EMPLOYEE (superclass):
Name       ← inherited
Ssn        ← inherited
Birth_date ← inherited
Address    ← inherited

// Specific/Local attribute (own):
Typing_speed ← specific

// Inherited relationships:
WORKS_FOR Department ← inherited
WORKS_ON  Project    ← inherited

✅ ما بيتورّث
1. كل الـ attributes من الـ superclass
2. كل الـ relationships من الـ superclass
3. وإذا كانت في hierarchy: بيورّث من كل predecessor superclasses

📌 Specific vs Local Attributes
الـ attributes الخاصة بالـ subclass بتتسمى "specific" أو "local" attributes.
مثال: TypingSpeed بتاعة SECRETARY
والـ subclass ممكن يشارك في specific relationships زيها.
مثال: HOURLY_EMP BELONGS_TO TRADE_UNION

🔄 Specialization vs Generalization — الفرق المهم!

⬇️ Specialization

بيبدأ من الـ Superclass ونعرّف الـ subclasses منها.

اتجاه Top-Down — من فوق لتحت

⬆️ Generalization

بيبدأ من entities متشابهة ونعمل Superclass مشتركة.

اتجاه Bottom-Up — من تحت لفوق

🚨 الفخ اللي بيقع فيه الناس في الامتحان!
Specialization = من superclass للـ subclasses (Top-Down)
Generalization = دمج entities في superclass واحدة (Bottom-Up)
السؤال "Specialization is the process of generating a superclass from different subclasses" → الجواب: FALSE! دي Generalization!

🔀 Disjointness Constraint — الـ 'd' والـ 'o'

الـ constraint دي بتحدد: هل entity ممكن يكون في أكتر من subclass في نفس الوقت؟

🔵 Disjoint (d) — لا تداخل

الـ entity يكون في واحدة بس من الـ subclasses.

موظف اسمه كـ "Secretary" مش ممكن يكون "Engineer" في نفس الوقت في نفس الـ specialization

🟡 Overlapping (o) — تداخل مسموح

الـ entity ممكن يكون في أكتر من subclass في نفس الوقت.

موظف ممكن يكون Part-Time وفي نفس الوقت Consultant → يظهر في الاتنين

📏 Completeness Constraint — Single Line vs Double Line

الـ constraint دي بتحدد: هل كل entities في الـ superclass لازم تكون في subclass؟

Single Line = Partial

بعض الـ entities في الـ superclass ممكن ما تكونش في أي subclass.

Notation

// In EER diagram: SINGLE LINE
EMPLOYEE ─── (d) → Subclasses

// Meaning:
Some EMPLOYEES have no subtype

Double Line = Total

كل entity في الـ superclass لازم تكون في على الأقل subclass واحدة.

Notation

// In EER diagram: DOUBLE LINE
EMPLOYEE ══ (d) → Subclasses

// Meaning:
Every EMPLOYEE must be in ≥1 subtype

📐 4 Types of Specialization + Cardinality — أهم جزء في الامتحان!

Total / Disjoint (T/D)

كل entity في superclass في exactly ONE subclass. المجموع = Total بالظبط.

Sum = Total

Total / Overlapping (T/O)

كل entity في superclass في على الأقل ONE subclass، وممكن أكتر. المجموع ≥ Total.

Sum ≥ Total

Partial / Disjoint (P/D)

بعض entities مش في أي subclass، وكل entity في subclass واحدة max. المجموع < Total.

Sum < Total

Partial / Overlapping (P/O)

الحالة الأعم — بعض entities مش في subclass، وممكن الموجودين يكونوا في أكتر من واحدة.

Any case

🔢 Cardinality Formula — اتحفظها!

بنفترض: Total Employees = 100, PartTime = 50, Consultant = 20

السؤال: إيه نوع الـ participation لو Permanent Employees = X؟

Sum = 50+20+X

حساب مجموع كل الـ subtypes

Sum = 100 بالظبط

→ T/D (X = 30)

Sum > 100

→ Overlapping (T/O أو P/O — مش واضح من الأرقام لوحدها)

Sum < 100

→ Partial (P/D هي الأوضح — بعض موظفين مش متصنفين)

X = 29 → P/D

Sum = 99 < 100 → Partial

99 ≤ 100 → consistent with Disjoint

Partial / Disjoint

X = 81 → Overlapping

Sum = 151 > 100 → Overlapping

T أو P? مش واضح من الأرقام

Overlapping (T or P)

X = 30 → T/D

Sum = 100 = 100 → Total

لا overlap → Disjoint

Total / Disjoint ✓

🚨 الـ Trick اللي بيقع فيه الكل!
لما Sum < Total → مش ممكن Overlapping يكون confirmed (بس ممكن يكون P/D)
لما Sum > Total → Overlapping مؤكد (P/O أو T/O حسب Coverage)
لما X = 30 بالظبط → T/D الوحيد الممكن

📋 مثال الامتحان الصعب (2025 Q31):
Total=100, PT=50, C=20, PE=40, intersection بين الـ 3 subtypes = 10 نفس الـ records.
Sum = 110 > 100 → Overlapping مؤكد. وطالما الـ intersection = 10 → unique coverage = 110 - overlaps ≥ 100 → التغطية Total.
Answer: Total / Overlapping

🗺️ Mapping EER to Relational Schema — الـ 4 Options

عندنا specialization فيها superclass C وm subclasses {S1, S2, ..., Sm}. إزاي نحولها لـ relational tables؟

Multiple Relations — Superclass + Subclasses

الخيار الآمن الشامل ✅

m+1 relations

Result Tables

EMPLOYEE(SSN, Name, Bdate, Addr)
SECRETARY(SSN, Typing_speed)  ← FK
TECHNICIAN(SSN, Tgrade)       ← FK
ENGINEER(SSN, Eng_type)       ← FK

✅ Works for: ANY specialization
(Total or Partial) + (Disjoint or Overlapping)

الـ PK بتاعة كل subclass هو نفس الـ PK بتاعة الـ superclass (foreign key)

Multiple Relations — Subclass Relations Only

كل subclass بياخد كل attrs الـ superclass

m relations

Result Tables

SECRETARY(SSN, Name, Bdate, Typing_speed)
ENGINEER(SSN, Name, Bdate, Eng_type)
// NO separate EMPLOYEE table

⚠️ Works ONLY for:
TOTAL specialization فقط!
لو Partial → employees مش في أي subclass هيتضيعوا

لو Overlapping → نفس الـ entity هيتكرر في أكتر من relation — valid بس مش recommended

Single Relation with ONE Type Attribute

table واحدة بـ discriminating attribute

1 relation

Result Table

EMPLOYEE(SSN, Name, Bdate,
  Typing_speed, Tgrade, Eng_type,
  Profession)  ← type attribute

// Example data:
1 | Ahmed | ... | NULL  | Civil | Engineer
2 | Sara  | ... | 100   | NULL  | Secretary

❌ Works ONLY for DISJOINT!
لو Overlapping → واحد بيكون Secretary وEngineer معاً → type attr واحد مش كفاية → violates uniqueness
لازم تعمل: PK = (SSN + Profession)

Total vs Partial: مش مهم هنا

Single Relation with MULTIPLE Type Attributes

Boolean flag لكل subclass

1 relation

Result Table

EMPLOYEE(SSN, Name, Bdate,
  Typing_speed, Tgrade, Eng_type,
  IsSecretary,   ← YES/NO
  IsTechnician,  ← YES/NO
  IsEngineer)    ← YES/NO

// Example: engineer+secretary:
1 | Ahmed | 100 | Civil | YES | NO | YES

✅ Works for BOTH:
Disjoint ✅ + Overlapping ✅
كل entity عنده m flags (YES/NO)

الفرق عن 8C: بدل type attribute واحد، عندك boolean flag لكل subclass — فالـ overlapping بيتحل

📊 Quick Summary Table — احفظها!

Option	# Tables	Total	Partial	Disjoint	Overlapping
8A	m+1	✓	✓	✓	✓
8B	m	✓ required	✗	recommended	valid, not recommended
8C	1	✓	✓	✓ required	✗
8D	1	✓	✓	✓	✓

🚨 الأكثر سؤالاً في الامتحانات:
"Option 8C works for Overlapping" → FALSE! فقط Disjoint
"Participation type doesn't affect the option" → FALSE! 8B requires Total
"Option 8A works for any type" → TRUE! ✓

🎯

EER Quiz — أسئلة حقيقية من Finals 2023/2024/2025

اختبر نفسك على كل المفاهيم اللي اتشرحت

Q1 Final 2023 — Q18

Specialization is the process of generating a superclass from different subclasses.

A True

B False

✅ FALSE! ده تعريف الـ Generalization مش Specialization.
• Specialization = Top-Down: من superclass لـ subclasses
• Generalization = Bottom-Up: من entities متشابهة نعمل superclass

Q2 Final 2024 — Q37

An entity that is a member of a subclass inherits:

A All attributes of the entity as a member of the superclass

B All relationships of the entity as a member of the superclass

C All weak entities of the entity as a member of the superclass

D A and B

✅ الـ subclass بتورّث الـ attributes كلها + الـ relationships كلها من الـ superclass. مفيش حاجة اسمها "weak entities inheritance".

Q3 Final 2024 — Q38 | Final 2023 — Q20

Mapping Enhanced EER to SINGLE RELATION with ONE TYPE ATTRIBUTE (Option 8C) works for a specialization whose subclasses are:

A Total

B Disjoint

C Partial

D Overlapping

✅ Option 8C يشتغل فقط مع Disjoint. لو كان Overlapping، entity واحدة ممكن تكون في أكتر من subclass → type attribute واحد مش كفاية → Uniqueness violation. Total vs Partial مش مهم هنا.

Q4 Final 2023 — Q20

Building one table to represent inheritance with ONE TYPE ATTRIBUTE in EER can be used to enforce OVERLAPPING and PARTIAL PARTICIPATION constraints.

A True

B False

✅ FALSE! One type attribute يشتغل بس مع Disjoint. Overlapping → محتاج Option 8D (multiple type attributes). كمان لو Partial مع Overlapping → الـ PK uniqueness بتتكسر (Dr. Ali's answer).

Q5 Final 2025 — Q40

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

A True

B False

✅ FALSE! الـ participation type مهم:
• Option 8B يشتغل فقط مع Total participation
• Option 8A يشتغل مع أي type
• Options 8C و8D مش مهم فيهم الـ Total/Partial

Q6 Final 2025 — Q29 | Final 2024 — Q28 | Final 2023 — Q33

Assume 3 types of employees: PartTime, Permanent, Consultant. Total employees = 100, PartTime = 50, Consultant = 20. If number of Permanent = 29, the participation type is:

A Total / Disjoint

B Total / Overlapping

C Partial / Disjoint

D None of the above

✅ Sum = 50 + 20 + 29 = 99 < 100
→ Partial (موظف واحد مش في أي subtype)
→ 99 ≤ 100 → consistent with Disjoint (مفيش overlap ضروري)
→ Partial / Disjoint ✓

Q7 Final 2025 — Q30 | Final 2024 — Q29 | Final 2023 — Q34

Same scenario: Total=100, PartTime=50, Consultant=20. If Permanent = 81, the participation type is:

A Total / Disjoint

B Total / Overlapping

C Partial / Disjoint

D Overlapping — could be Total or Partial

✅ Sum = 50 + 20 + 81 = 151 > 100
→ Overlapping مؤكد (بعض الموظفين في أكتر من subtype)
→ هل Total أو Partial؟ مش واضح من الأرقام لوحدها → "Overlapping (T or P)"
Dr. Ali: "Overlapping and Maybe Partial or Total"

Q8 Final 2025 — Q31

Total=100, PartTime=50, Consultant=20, Permanent=40. Intersection among ALL THREE subtypes = 10 records (same 10 records). The participation type is:

A Total / Disjoint

B Total / Overlapping

C Partial / Disjoint

D None of the above

✅ Sum = 50 + 20 + 40 = 110 > 100 → Overlapping مؤكد
Intersection = 10 (نفس 10 موظفين في الـ 3 types) → unique employees covered ≥ 100 → Total
→ Total / Overlapping ✓

Q9 — EER Concept

Which mapping option creates the MAXIMUM number of relational tables?

A Option 8A

B Option 8B

C Option 8C

D Option 8D

✅ Option 8A → m+1 tables (1 للـ superclass + 1 لكل subclass)
Option 8B → m tables
Options 8C و8D → 1 table فقط

Q10 — EER Concept

A member of a superclass CAN optionally be a member of any number of its subclasses.

A True

B False

✅ TRUE! من السلايدز: "A member of the superclass can be optionally included as a member of any number of its subclasses." — مثال: موظف مهندس ومدير وبياخد مرتب ثابت → في 3 subclasses معاً.

Functional Dependencies & Normalization

Redundancy · FDs · 1NF · 2NF · 3NF

⚠️ Redundancy & Anomalies — المشكلة اللي هنحلها

لما بنحط معلومات مختلفة في table واحدة بتحصل Redundancy = تكرار البيانات. وده بيسبب 3 مشاكل:

❌ Insertion Anomaly

مش ممكن تضيف department جديد من غير employee — الـ PK هيكون NULL وده ممنوع!

⚠️ Deletion Anomaly

لو حذفت آخر موظف في department، بتحذف معاه كل معلومات الـ department!

🔄 Modification Anomaly

لو غيرت اسم الـ department، لازم تغيره في كل الـ rows — نسيان واحد → inconsistency!

EMP_DEPT — Example of Redundancy Problem

Ename        | Ssn       | Dnumber | Dname        | Dmgr_ssn
Smith        | 123456789 | 5       | Research     | 333445555
Wong         | 333445555 | 5       | Research     | 333445555  ← repeated!
Narayan      | 666884444 | 5       | Research     | 333445555  ← repeated!
English      | 453453453 | 5       | Research     | 333445555  ← repeated!
// "Research" dept info repeated for EVERY employee in dept 5!

🔗 Functional Dependencies (FD) — الأساس

تعريف: X → Y يعني: لو tuple تانين ليهم نفس قيمة X، لازم يكون عندهم نفس قيمة Y.

FD Examples

// SSN determines all employee info:
SSN → Ename, Bdate, Address, Dnumber

// Department number determines dept info:
Dnumber → Dname, Dmgr_ssn

// Composite key determines hours:
{SSN, Pnumber} → Hours

✅ Direct (Full) Dependency

كل attribute بيعتمد على الـ PK بالكامل

StudentId → Name, DOB, Address

⚠️ Partial Dependency

attribute بيعتمد على جزء من composite PK — violates 2NF

SSN → Ename (في table PK={SSN,Pno})

🔄 Transitive Dependency

attribute بيعتمد على non-key attr — violates 3NF

SSN → Dno → Dname

1️⃣ First Normal Form (1NF)

القاعدة: كل خلية في الـ table لازم تكون atomic = قيمة واحدة بس.

❌ يخالف 1NF:
• Multi-valued attributes — موظف عنده أكتر من phone number في خلية واحدة
• Composite attributes — الـ Name مش atomic
• Nested relations — table جوا table
• Repeated groups — أكتر من قيمة في نفس الخلية

NOT in 1NF

// DEPARTMENT table — multi-valued Dlocations:
Dnumber | Dname    | Dlocations
5       | Research | {Bellaire, Sugarland, Houston}
// ↑ NOT ATOMIC! Multiple values in one cell

✅ Fix — قسّم لـ separate relations:

IN 1NF — After fix

// DEPARTMENT:
Dnumber | Dname    | Dmgr_ssn

// DEPT_LOCATIONS (separate table):
Dnumber | Dlocation
5       | Bellaire
5       | Sugarland
5       | Houston
// PK = {Dnumber, Dlocation}

📌 يمين: لازم يكون في PK محددة عشان تعتبر الـ relation in 1NF. من غير PK → technically not 1NF

2️⃣ Second Normal Form (2NF)

الشرط: in 1NF + لا يوجد Partial Dependency

Partial Dependency = attribute بيعتمد على جزء من الـ composite PK بس، مش الـ composite key كله.

❌ EMP_PROJ — violates 2NF:

Partial Dependencies Found!

// EMP_PROJ(SSN, Pnumber, Hours, Ename, Pname, Ploc)
// PK = {SSN, Pnumber}

{SSN, Pnumber} → Hours        ← FULL ✓
SSN            → Ename        ← PARTIAL ✗
Pnumber        → Pname, Ploc  ← PARTIAL ✗

✅ Fix — فصّل كل dependency في relation منفصلة:

2NF — After Decomposition

// EP1: Full dependency only
EP1(SSN, Pnumber, Hours)
// {SSN, Pnumber} → Hours ✓

// EP2: SSN partial dep
EP2(SSN, Ename)
// SSN → Ename ✓

// EP3: Pnumber partial dep
EP3(Pnumber, Pname, Plocation)
// Pnumber → Pname, Ploc ✓

Note: 2NF only relevant when PK is composite. Single PK → automatically in 2NF.

3️⃣ Third Normal Form (3NF)

الشرط: in 2NF + لا يوجد Transitive Dependency

Transitive Dependency = A → B → C حيث B هي non-key attribute.

بمعنى تاني: مفيش non-key attribute يحدد non-key attribute تاني

❌ EMP_DEPT — violates 3NF:

Transitive Dependency Found!

// EMP_DEPT(Ename, SSN, Bdate, Addr, Dno, Dname, Dmgr)
// PK = SSN

SSN  → Ename, Bdate, Addr, Dno  ← direct ✓
Dno  → Dname, Dmgr_ssn            ← Dno is non-key!

// So transitively:
SSN → Dno → Dname, Dmgr  ← TRANSITIVE ✗

✅ Fix — افصل الـ transitive dependency:

3NF — After Fix

// ED1: Employee info (keep Dno as FK)
ED1(SSN, Ename, Bdate, Address, Dno)
// SSN → Ename, Bdate, Addr, Dno ✓

// ED2: Department info (separate!)
ED2(Dno, Dname, Dmgr_ssn)
// Dno → Dname, Dmgr ✓

🧩 الـ method:
1. حدد الـ transitive deps
2. كل transitive dep → relation جديدة
3. الـ determinant (Dno) يبقى FK في الـ original table وPK في الجديدة

📖 Full Example — Reservation System (من السلايدز)

هناخد الـ Reservation relation دي ونطبق عليها 2NF وبعدين 3NF:

Original Relation + FDs

Reservation(PerformerId, AgentId, VenueId, EventId,
  PerformerName, PerformerLoc, PerformerType, Fee,
  AgentName, AgentLoc, EventType, EventName,
  VenueName, VenueLoc, BookingDate)

// FDs:
{PerformerId,AgentId,VenueId,EventId} → BookingDate
EventId      → EventType, EventName
VenueId      → VenueName, VenueLocation
AgentId      → AgentName, AgentLocation
PerformerId  → PerformerName, PerformerLoc, PerformerType
PerformerType → Fee

Step 1: 2NF — Remove Partial Deps

After 2NF

Performer(PerformerId, PName, PLoc, PType, Fee)
Event(EventId, EventType, EventName)
Agent(AgentId, AgentName, AgentLoc)
Venue(VenueId, VenueName, VenueLoc)
Reservation(PerformerId, AgentId, VenueId,
            EventId, BookingDate)

Performer هل هي in 3NF؟ PerformerType→Fee → Transitive! لازم نفصله.

Step 2: 3NF — Remove Transitive Deps

After 3NF

Performer(PerformerId, PName, PLoc, PType)
PerformerType(PerformerType, Fee) ← new!
Event(EventId, EventType, EventName)
Agent(AgentId, AgentName, AgentLoc)
Venue(VenueId, VenueName, VenueLoc)
Reservation(PerformerId, AgentId, VenueId,
            EventId, BookingDate)

الآن كل relation in 3NF — مفيش partial أو transitive deps!

🔍 كيف تحدد الـ Normal Form؟

Normal Form	الشرط اللي لازم ينطبق	الـ Violation اللي بتكسرها
1NF	قيم atomic + PK محددة	Multi-valued / composite attrs
2NF	in 1NF + no partial deps	Non-key attr depends on PART of composite PK
3NF	in 2NF + no transitive deps	Non-key attr determines another non-key attr

🎯

Normalization Quiz — أسئلة حقيقية من Finals 2023/2024/2025

اختبر فهمك للـ FDs والـ Normal Forms

Q1 Final 2025 — Q45 | Final 2024 | Final 2023 — Q1

A functional dependency is a relationship between:

A Entities

B Attributes

C Tuples

D Tables

✅ FD هي relationship بين Attributes. X → Y يعني كل ما قيمة X تتكرر، نفس قيمة Y بتظهر. Dr. Ali: "c. Attributes"

Q2 Final 2025 — Q46 | Final 2023 — Q3

Every time a certain value of attribute A appears, it matches the same value of attribute B, but NOT the same value of C. Therefore it is true that:

A A → C

B B, C → A

C A → B

D A → B, C

✅ لما A يظهر → نفس قيمة B دايماً = A → B ✓
لما A يظهر → مش نفس قيمة C = A لا يحدد C → A → C ✗
Dr. Ali: c. A → B

Q3 Final 2025 — Q47 | Final 2023 — Q4

Given: StudentId → StuName, CourseId → CourseName, (StudentId, CourseId) → Grade. The 2NF decomposition is:

A (StudentId, StuName), (CourseId, CourseName), (StudentId, CourseId, Grade)

B (StudentId, StuName, Grade), (CourseId, CourseName), (StudentId, CourseId)

C (StudentId, StuName), (CourseId, CourseName, Grade), (StudentId, CourseId)

D (StudentId, CourseId), (StuName, CourseName, Grade)

✅ PK = {StudentId, CourseId} — composite
• StudentId → StuName = Partial dep → Student(StudentId, StuName)
• CourseId → CourseName = Partial dep → Course(CourseId, CourseName)
• {StudentId, CourseId} → Grade = Full dep → Enroll(StudentId, CourseId, Grade)
Dr. Ali: a

Q4 Final 2023 — Q2

Given: {DEPT, COURSE, SECTION} → ROOM, INSTR and INSTR → I_OFFICE. The 3NF decomposition is:

A (DEPT, COURSE, SECTION, ROOM, INSTR), (INSTR, I_OFFICE)

B (DEPT, COURSE, SECTION, ROOM), (INSTR, I_OFFICE)

C (DEPT, COURSE, SECTION), (ROOM, INSTR), (INSTR, I_OFFICE)

D (DEPT, COURSE, SECTION), (INSTR, I_OFFICE, ROOM)

✅ الـ transitive dependency هي: PK → INSTR → I_OFFICE
Fix: فصّل INSTR → I_OFFICE في relation جديدة (INSTR, I_OFFICE)
الـ original table بيفضل يحتفظ بـ ROOM و INSTR (INSTR بقى FK)
Dr. Ali: a

Q5 Final 2024 — Q20

A table stores StudentID (PK), CourseID (PK), StudentName, CourseName, and Grade where (StudentID, CourseID) is the composite key. Which statement is MOST TRUE?

A The table is already in 3NF

B The table suffers from partial dependency on StudentName

C The table is in 1NF but violates higher normal forms

D The table design is efficient and avoids unnecessary redundancy

✅ الـ table in 1NF ✓ (atomic values, PK defined)
لكن: StudentID → StudentName (Partial dep → violates 2NF)
CourseID → CourseName (Partial dep → violates 2NF)
→ in 1NF but violates 2NF and 3NF
Dr. Ali: c

Q6 Final 2024 — Q22 | Final 2025 — Q23

A database D contains 3 entities: E1 in 2NF, E2 in 3NF, and E3 contains multi-valued attributes. The database is in:

A 1st Normal Form

B 2nd Normal Form

C 3rd Normal Form

D Denormalized

✅ الـ DB بتاخد الـ NF الأضعف بين الـ tables.
E3 عندها multi-valued attributes → violates 1NF → below 1NF → Denormalized!
مش مهم إن E1 in 2NF وE2 in 3NF — الأضعف هو اللي بيحدد.
Dr. Ali: a. Denormalized

Q7 Final 2024 — Q24

Once the database model reaches Relational Model (with primary keys defined), all its relations are in at least:

A 1st Normal Form

B 2nd Normal Form

C 3rd Normal Form

D Denormalized

✅ لما الـ relation تيجي في الـ Relational Model مع PK محددة → اتلحقت بشروط الـ 1NF (atomic values, defined key).
لكن مش ضامن 2NF أو 3NF (ممكن يكون فيه partial أو transitive deps).
Dr. Ali: a. 1st NF

Q8 — Concept

Which type of dependency VIOLATES 2NF but NOT necessarily 1NF?

A Transitive dependency

B Full dependency

C Partial dependency

D Direct dependency

✅ Partial Dependency = يخالف 2NF (attr يعتمد على جزء من الـ composite PK).
Transitive = يخالف 3NF.
Full/Direct dependency = مطلوبة في 2NF و3NF.

Q9 Final 2024 — Q13

Table: (OrderID, ProductID, Quantity, UnitPrice, TotalPrice) where TotalPrice = Quantity × UnitPrice, and PK = (OrderID, ProductID). What normal form?

A 1st NF

B 2nd NF

C 3rd NF

D 0 NF

✅ الـ table in 1NF (atomic values, PK defined) ✓
لكن: UnitPrice → هو سعر المنتج، بيعتمد على ProductID فقط (مش الـ composite PK كامل) → Partial Dependency → violates 2NF
كمان TotalPrice مشتقة (derived) من Quantity × UnitPrice.
Dr. Ali: a. 1st NF

Q10 — Concept

Which statement correctly describes 3NF?

A All attributes depend on the PRIMARY KEY only

B No attribute depends on part of a composite key

C In 2NF with no non-key attribute determining another non-key attribute

D All relations have a single primary key attribute

✅ 3NF = in 2NF + no transitive dependencies = مفيش {non-key → non-key}
Option A يصف 2NF نوعاً ما.
Option B يصف 2NF (removing partial deps).
Option C هو التعريف الصحيح للـ 3NF.

📋

Cheat Sheet — ملخص للمراجعة السريعة

احفظ الجدول ده ادخل الامتحان بثقة!

🏗️ EER — المفاهيم الأساسية

Specialization

Top-Down: من Superclass لـ Subclasses — بتعرّف الـ subclasses

Generalization

Bottom-Up: من entities متشابهة تعمل Superclass واحدة

Inheritance

Subclass ترث ALL attributes + ALL relationships من الـ Superclass

Local/Specific Attrs

الـ attributes الخاصة بالـ subclass (مش موروثة)

Subclass rule

لازم تكون member في الـ Superclass الأول — مش ممكن في Subclass لوحدها

🔀 Constraints — الـ d و o والـ single/double line

Disjoint (d)

Entity في واحدة بس من الـ subclasses — لا تداخل

Overlapping (o)

Entity ممكن في أكتر من subclass — تداخل مسموح

Total (double line ══)

كل entity في الـ superclass لازم في على الأقل subclass واحدة

Partial (single line ─)

بعض entities ممكن ما تكونش في أي subclass

📐 Cardinality Formula — السؤال اللي بيجي كل سنة

Sum = Total بالظبط

→ Total / Disjoint (T/D)

Sum > Total

→ Overlapping مؤكد (T/O أو P/O — مش واضح)

Sum < Total

→ Partial مؤكد (P/D هي الأوضح)

T=100,PT=50,C=20,PE=29

Sum=99 < 100 → Partial/Disjoint ✓

T=100,PT=50,C=20,PE=81

Sum=151 > 100 → Overlapping (T or P)

T=100,PT=50,C=20,PE=30

Sum=100 = 100 → Total/Disjoint ✓

🗺️ Mapping Options — الـ 4 خيارات

Option 8A

Superclass table + subclass tables = m+1 tables. يشتغل مع ANY type ✅

Option 8B

Subclass tables only = m tables. يشتغل مع TOTAL فقط. Recommended for D.

Option 8C

1 table + type attr. يشتغل مع DISJOINT فقط. لو Overlapping → violates uniqueness.

Option 8D

1 table + m boolean flags. يشتغل مع D و O معاً ✅

Participation effect?

YES! 8B needs TOTAL. الـ participation type بيأثر على الـ option اللي بنختاره.

📊 Normal Forms Summary

1NF

Atomic values + PK defined. No multi-valued, composite, or nested attrs.

2NF

in 1NF + No PARTIAL dependencies (all non-key → full PK)

3NF

in 2NF + No TRANSITIVE dependencies (no non-key → non-key)

FD is between

ATTRIBUTES (مش entities أو tuples أو tables)

Partial dep

Attr depends on PART of composite PK → Fix by splitting

Transitive dep

PK → A → B where A is non-key → Fix by separating (A, B)

DB NF level

= الـ NF للـ table الأضعف. لو table in 1NF → DB in 1NF max

Multi-valued in table

→ Denormalized (below 1NF) → DB is Denormalized

🚨 Exam Traps — الأكثر غلطاً

"Spec. generates superclass"

→ FALSE! ده Generalization. Specialization بتعمل Subclasses من Superclass.

"8C works for Overlapping"

→ FALSE! 8C فقط للـ Disjoint. Overlapping محتاج 8D.

"Participation doesn't matter"

→ FALSE! 8B needs Total. Type of participation DOES matter.

Sum < Total → مؤكد P/D

→ مش دايماً! يمكن P/O — لكن P/D هو الجواب الأوضح في الامتحان.

"FD between entities"

→ FALSE! FD بين Attributes، مش entities أو tables.

"2NF no transitive"

→ FALSE! الـ transitive يخالف 3NF مش 2NF. 2NF عن الـ partial deps.

Subclass يرث weak entities

→ FALSE! بيرث attributes + relationships بس.

Single PK → 2NF auto?

→ YES! لو PK مش composite → مفيش partial deps ممكنة → automatically in 2NF.

Database SystemsEER Model & Normalization

Enhanced Entity-Relationship (EER) Model

Total / Disjoint (T/D)

Total / Overlapping (T/O)

Partial / Disjoint (P/D)

Partial / Overlapping (P/O)

EER Quiz — أسئلة حقيقية من Finals 2023/2024/2025

Functional Dependencies & Normalization

Normalization Quiz — أسئلة حقيقية من Finals 2023/2024/2025

Cheat Sheet — ملخص للمراجعة السريعة

🏗️ EER — المفاهيم الأساسية

🔀 Constraints — الـ d و o والـ single/double line

📐 Cardinality Formula — السؤال اللي بيجي كل سنة

🗺️ Mapping Options — الـ 4 خيارات

📊 Normal Forms Summary

🚨 Exam Traps — الأكثر غلطاً

Database Systems
EER Model & Normalization