Chapter 3: Relational Data

Model

1
Outline
• Structure of Relational Database
• Conceptual Data Model to Relational Model Mapping
• From E/R Diagram to Relational Model
• From ODL Model to Relational Model
• Dependencies
• Functional Dependencies
• Multivalued Dependencies
• Normal Forms and Normalization
• First Normal Form (1NF)
• Second Normal Form (2NF)
• Third Normal Form (3NF)
• Boyce-Codd Normal Form (BCNF)
• Fourth Normal Form (4NF)
• Fifth Normal Form (5NF or PJNF)
2
Introduction to Relational Data
Model
•Used in Relational Database Management Systems (RDBMS).
•Organizes data in tables (relations).
•Based on mathematical set theory (Operations like union,
intersection,
difference, and Cartesian product) and logic (SELECT-FROM-
WHERE).

3
3.1 Structure of Relational
Database
•Data is represented as two-dimensional
tables.
•A relation consists of:
•Attributes (Columns)
•Tuples (Rows)

•Example: EMPLOYEES Table

4
 Example of Relational Table

Table: EMPLOYEES

EmpId Name BDate Sub City Kebele Phone

E001 Alemu Girma 01/10/70 Bole 06 011-663-0712
E004 Kelem Belete 12/04/68 Gulele 03 011-227-2525

5
Relation Schema and Instance

•Relation Schema: Defines structure of a

table.
•Relation Instance: Actual data stored in the
table.
•Example schema:
Employees(EmpId: string, Name: string, BDate: date, SubCity: string, Kebele: integer, Phone:
string)

6
 Properties of Relations
•Tuples are unique (No duplicate rows).
•Order of tuples is not important.
•Attributes are atomic (Each column has indivisible
values).
•Values must match attribute domains.

7
 Key Constraints
•Ensures uniqueness and integrity.
•Candidate Key: Minimal set of attributes that uniquely identifies
a row.
•Primary Key: Chosen candidate key.
Example: EmpId in EMPLOYEES table

8
 Foreign Key Constraints

•Foreign Key: Attribute that refers to the primary key in another

table.
•Ensures referential integrity
Example: Employee in WorkSchedule references EmpId in EMPLOYEES

9
Referencing and Referenced
Relations

•Employee references EMPLOYEES.

•Ensures data consistency in relational model.

10
3.2 Conceptual Data Model to
Relational Model Mapping
•Transform E/R diagrams into relational schemas.
Example:
•Entity Set: EMPLOYEES → Relation: Employees(EmpId, Name, BDate, SubCity,

Kebele, Phone).

11
12
 3.2.1 E/R Diagram to Relational
Model
•Convert entities and relationships into relational
tables.
•Example:
•Projects(ProjId, Name, SDate, DDate)
•Customers(CustId, Name, Address)

13
 Entity Sets to Relations
•Strong entity sets → Relations with same name and
attributes.
•Primary keys remain unchanged.

14
Weak Entity Sets

•Depends on a strong entity.

•Requires a discriminator and foreign key.
Example: Teams(ProjId, Name, Descr)

15
Composite & Multivalued
•Attributes
Composite attributes → Split into separate
attributes.
•Employee (Emp_ID, Name, Address).

•Multivalued attributes → Stored in separate

relation.
•Student (Student_ID, Name, {Phone_Number}).

Example:
Addresses(City, SubCity, Kebele, HNo, Phone1, Phone2, EmpId)

16
Relationship Sets to Relations
•Relationship mapped as a new relation.
•Contains foreign keys from participating
entities.
•Example:
Assigned(EmpId, ProjId, TeamName)

17
Generalization & Specialization
•Generalization: Combining similar
entities.
•Specialization: Creating sub-entities.
Example: Specialization
FullTimeEmployees(EmpId, Salary, Allowance)

18
3.2.2 ODL Model to Relational
Model
•Object Definition Language (ODL) maps to relational
schema.
•Classes converted to tables.
Example:
Employees(EmpId, Name, Age, Gender, City, HAddr, Phone)

19
3.3 Dependencies

• In a database design the two most common pitfalls that

result in bad designing are:
1. Repetition of information, and

2. Inability to present certain information (Loss of

information).

20
 3.3.1 Functional
•Functional Dependencies
dependency (FD) is a relationship between
attributes in
a relation (table) where one attribute uniquely determines
another.
• Notation:
If X → Y, then the value of X uniquely determines the value of
Y.

21
 3.3.1 Functional Dependencies
• Example1:
Student_ID Name Course
101 John Math
102 Emma Science

• Student_ID → Name → Knowing the Student_ID gives a

unique Name.

• Course → Name ❌ (Invalid) → Multiple students can take

the same course.

22
FD
Example2:
StudentID (PK) Name Department Advisor
101 Alice CS Dr. Stone
102 Bob IT Dr. Kim
103 Carol CS Dr. Stone
104 Daniel Math Dr. Singh

Functional Dependencies:
1.StudentID → Name, Department, Advisor
(A student ID uniquely determines all other attributes.)
2.Department → Advisor
(Assuming each department has one advisor, e.g., CS always has
Dr. Stone.)
23
FD
• Example3:
OrderID (PK) CustomerID CustomerName ProductID Quantity
5001 C01 Selam P001 3
5002 C02 Tadesse P002 1
5003 C01 Selam P003 2

Functional Dependencies:
1.OrderID → CustomerID, ProductID, Quantity
(Each order ID uniquely determines the order details.)
2.CustomerID → CustomerName
(CustomerID uniquely identifies the customer name, even across
multiple orders.)

24
 3.3.2 Multivalued Dependencies
•A Multivalued Dependency (MVD) occurs when the presence of certain attribute values
implies the
presence of multiple independent attribute values in a relation.
• Notation:
If X →→ Y, then for each value of X, there exists a set of values for Y, independent of other
attributes.

25
 3.3.2 Multivalued Dependencies
• Example1:
Student_ID Course Hobby
101 Math Chess
101 Math Music
101 Science Chess
101 Science Music

• Student_ID →→ Course (A student can enroll in multiple

courses).
• Student_ID →→ Hobby (A student can have multiple hobbies).
• Course and Hobby are independent of each other for the same
Student_ID.
26
MD
• Example2:
EmpID Skill
1 Java
1 SQL
2 Networking
2 Python
2 Linux

Multivalued Dependency:
EmpID↠Skill

27
MD
• Example3:
BookID Author Topic
B1 John Smith Databases
B1 Emma Clark Databases
B1 John Smith SQL
B1 Emma Clark SQL
B2 Sarah Jones AI
B2 David Kim AI
B2 Sarah Jones Machine Learning
B2 David Kim Machine Learning

Multivalued Dependencies:
1.BookID →→ Author
2.BookID →→ Topic
28
 Type Room
ID

Name Room Room

Number
Hotel M
HotelOffer
ID 1 s 1
Price

Hotel
Location Room Is
Booked In

M Reservation
ID
Guest
ID
CheckInDate
1 Guest M Reservation
Full Name
Guest Makes
CheckOutDate

Email Status

Phone

ER Diagram for hotel‐reservation System Database

 Mapping to Relational Database Model

• Hotel
HotelID (PK) Name Location
1 Grand Addis Addis Ababa
2 Lakeside Resort Bahir Dar
3 Rift Valley Inn Hawassa

• Room
RoomID (PK) HotelID (FK) RoomNumber Type Price
101 1 A101 Single 50.00
102 1 A102 Double 75.00
103 1 A103 Suite 120.00
201 2 B201 Double 80.00
202 2 B202 Suite 150.00
301 3 C301 Single 55.00
• Guest
GuestID (PK) FullName Email Phone
1 Selam Bekele selam@example.c +251912345678
om
2 Tadesse Alem tade@example.co +251911234567
m
3 Hana Solomon hana.s@example.c +251913333444
om
4 Michael Tesfaye michael.t@exampl +251914444555
e.com

• Reservation
Reservation GuestID RoomID CheckInDat CheckOutD
Status
ID (PK) (FK) (FK) e ate
1001 1 101 2025‑05‑20 2025‑05‑25 Confirmed
1002 2 201 2025‑06‑01 2025‑06‑05 Pending
1003 3 103 2025‑06‑10 2025‑06‑12 Confirmed
1004 1 202 2025‑07‑01 2025‑07‑04 Checked‑In
1005 4 301 2025‑07‑15 2025‑07‑20 Cancelled
 Normalization & Its Importance
• In relational databases, normalization is a process that
helps to
• Eliminates redundancy,

• Organizes data efficiently,

• Reduces the potential for anomalies during data operations, and

• Improves data consistency.

32
First
A table isNormal Form
in First Normal Form (1NF)
(1NF) if:
• All attributes contain atomic (indivisible)
values.
• Each column contains values of a single
type.
• Each row has a unique identifier (Primary
Key).
• No repeating groups or multivalued
attributes.

33
First Normal Form (1NF)
• Example 1:
Student_ID Name Course
101 John Math, Science
102 Emma Physics

❌ Issues:
• Course column contains multiple values (not atomic).
• Converting to 1NF
• ✅ Create separate rows for each value:
Student_ID Name Course
101 John Math
101 John Science
102 Emma Physics

• Now, the table follows 1NF rules!

34
 1NF
• Example2:
EmpID Name PhoneNumbers
101 Alice 0911122333, 0922344556
102 Bob 0933111222
103 Carol 0922111333, 0911223344

Issue:
•The PhoneNumbers attribute contains multiple phone numbers in a single field.
•This violates 1NF, which requires atomic (indivisible) values in every attribute.

EmpID Name PhoneNumber

101 Alice 0911122333
101 Alice 0922344556
102 Bob 0933111222
103 Carol 0922111333
103 Carol 0911223344
35
 Partial Dependency
• Relation: StudentCourseMarks
StudentID CourseID StudentName CourseName Marks
1 C101 Alice DBMS 85
2 C102 Bob Networks 78
3 C101 Carol DBMS 92

Primary Key: (StudentID, CourseID)

Partial Dependencies:
•StudentName depends only on StudentID, not the full (StudentID,
CourseID)
•CourseName depends only on CourseID 36
 Second Normal Form (2NF)
A table is in Second Normal Form (2NF) if:

• It is already in First Normal Form (1NF).

• No Partial Dependencies exist (i.e., every non-key attribute must depend on the entire
primary key,

not just part of it).

Example:
Order_ID Product_ID Product_Name Customer_Name
1 P1 Laptop Alice
1 P2 Mouse Alice
2 P3 Keyboard Bob

❌ Issues:
• Composite Primary Key: (Order_ID, Product_ID)
• Product_Name depends only on Product_ID (Partial Dependency). 37
 Second Normal Form (2NF)
• Converting to 2NF
✅ Decompose the table into two separate tables:

38
2NF
• Example 2:
Relation:TeacherSubjects
OrderID ProductID ProductName UnitPrice Quantity
101 P01 Keyboard 500 2
101 P02 Mouse 150 1
102 P01 Keyboard 500 1
103 P03 Monitor 3000 2

Primary Key: (TeacherID, SubjectID)

• Partial Dependencies (violating 2NF):
• TeacherName depends only on TeacherID
• SubjectName and Room depend only on SubjectID
39
2NF
• These are partial dependencies, so the table is not in 2NF.
• Decomposition into 2NF
• We split the table into three relations:
TeacherID TeacherName
T01 Mr. Smith
T02 Ms. Clark
T03 Mr. Daniel

SubjectID SubjectName Room

S01 Math R101
S02 Physics R102
S03 Chemistry R103

40
2NF
TeacherID SubjectID
T01 S01
T01 S02
T02 S01
T03 S03

• Now in 2NF Because:

• Every non-key attribute is fully functionally dependent on the whole
key
• All partial dependencies have been eliminated
• Structure is clean, consistent, and non-redundant

41
Transitive Dependency
• Consider a table Employee:
EmpID (PK) EmpName DeptID DeptName
1 Alice 10 Engineering
2 Bob 20 Marketing
3 Carol 10 Engineering
4 Dave 30 Human Resources

• PK = EmpID
• Non‑key attributes: EmpName, DeptID, DeptName
• Functional Dependencies
• EmpID → EmpName, DeptID

• DeptID → DeptName 42
Transitive Dependency
• Because of (2), DeptName depends on DeptID, and DeptID depends on
the key EmpID (by (1)), we have:
• EmpID → DeptID → DeptName
• Thus there is a transitive dependency:
• EmpID → DeptName (via DeptID)

43
 Third Normal Form (3NF)
• A table is in Third Normal Form (3NF) if:
• It is already in Second Normal Form (2NF).

• It has no Transitive Dependencies (i.e., non-key attributes must depend only on the primary key and
not on other non-key attributes).

• Example:

❌ Issue
• Department_Name depends on Department_ID, not directly on Employee_ID
(Transitive Dependency).
44
 Third Normal Form (3NF)
• Converting to 3NF
✅ Decompose into separate tables:

• Now, the table is in 3NF! 🎯

45
3NF
• Invoices
InvoiceID (PK) InvoiceDate CustomerID CustomerName CustomerAddress
123 Main St,
1001 2025-05-10 C001 Acme Corp
Springfield
456 Elm St,
1002 2025-05-11 C002 Beta LLC
Shelbyville
123 Main St,
1003 2025-05-12 C001 Acme Corp
Springfield
… … … … …

• Functional Dependencies
• InvoiceID → InvoiceDate, CustomerID
• CustomerID → CustomerName, CustomerAddress
• Because of (2), CustomerName and CustomerAddress depend on
CustomerID, which itself depends on InvoiceID (the primary key). That
creates: 46
• InvoiceID → CustomerID → CustomerAddress
• Hence, CustomerAddress is transitively dependent on InvoiceID,
violating Third Normal Form.
• Decomposition into 3NF
• A. Invoices
InvoiceID (PK) InvoiceDate CustomerID (FK)
1001 2025-05-10 C001
1002 2025-05-11 C002
1003 2025-05-12 C001
… … …

47
• Now all non‑key attributes (InvoiceDate, CustomerID) depend directly
on the PK (InvoiceID).
• B. Customers
CustomerID (PK) CustomerName CustomerAddress
C001 Acme Corp 123 Main St, Springfield
C002 Beta LLC 456 Elm St, Shelbyville
… … …

• Here, CustomerName and CustomerAddress depend directly on

CustomerID (the PK).

48
 Boyce-Codd Normal Form
(BCNF)
A table is in Boyce-Codd Normal Form (BCNF) if:
• It is already in Third Normal Form (3NF).
• Every determinant is a candidate key (i.e., no partial dependency on a non-candidate key).
Example:

❌ Issue:
• Course → Instructor (Each course is taught by only one instructor).
• Student_ID, Course is the primary key, but Course alone determines
Instructor,
• violating BCNF. 49
Boyce-Codd Normal Form
(BCNF)
• Converting to BCNF
✅ Decompose into two tables:

• Now, the tables are in BCNF! 🎯

50
BCD
• CourseEnrollments Table
StudentID CourseCode Instructor
S1 CS101 Prof. A
S2 CS101 Prof. A
S3 CS102 Prof. B
S4 CS103 Prof. C
S5 CS102 Prof. B

• Functional Dependencies:
• StudentID + CourseCode → Instructor ✅ (Instructor for that student in that
course)

• CourseCode → Instructor ❌ (Each course has only one instructor)

51
BCD
• The primary key is: StudentID + CourseCode

• But there is also a partial dependency: CourseCode → Instructor

• This table is in 3NF:

• All non-prime attributes (Instructor) depend only on superkeys or candidate keys.

• There are no transitive dependencies.

• But it violates BCNF, because:

• CourseCode → Instructor is a functional dependency

• CourseCode is not a superkey, so this breaks the rule for BCNF.

52
• Candidate Keys:
• Why BCNF Is Stricter Than 3NF
• In BCNF, for every functional dependency X → Y, X must be a
superkey.
• Step 2: Decompose into BCNF
• We decompose the relation into two:
CourseCode Instructor
CS101 Prof. A
CS102 Prof. B
CS103 Prof. C

53
• CourseCode is now the primary key.
• Enrollments Table
StudentID CourseCode
S1 CS101
S2 CS101
S3 CS102
S4 CS103
S5 CS102

• StudentID + CourseCode is the primary key.

• No functional dependencies other than the key. 54

 Fourth Normal Form (4NF)
A table is in Fourth Normal Form (4NF) if:
• It is already in Third Normal Form (3NF).

• It has no Multivalued Dependencies (MVDs) (i.e., independent multivalued attributes must be stored
in separate

tables).

Example:

❌ Issue:
• Student_ID →→ Course (A student can take multiple courses).
• Student_ID →→ Hobby (A student can have multiple hobbies).
55
• Course and Hobby are independent of each other, causing redundancy.
Fourth Normal Form (4NF)
• Converting to 4NF
✅ Decompose into two separate tables:

Now, the tables are in 4NF! 🎯

56
Join Dependency
• SupplierParts
Supplier Part Project
S1 P1 J1
S1 P2 J1
S2 P1 J2

• This relation stores which supplier supplies which part for which
project.

57
• Now let’s Decompose into 3 Projections:
R1 = π(Supplier, Part)
Supplier Part
S1 P1
S1 P2
S2 P1

R2 = π(Supplier, Project)
Supplier Project
S1 J1
S2 J2

R3 = π(Part, Project)
Part Project
P1 J1
P2 J1
P1 J2
58
• Now Join R1, R2, and R3:
• We try to reconstruct the original table by joining:
• R1 ⨝ R2 ⨝ R3
• But the join produces extra rows that weren’t in the original table —
spurious tuples. For example:
Supplier Part Project
S1 P1 J2 ❌ (not in original)
S2 P1 J1 ❌ (not in original)

• This means the original relation cannot be reconstructed exactly from R1,
R2, and R3.
• So, Join Dependency Does NOT Hold Here.
• Because:
59
• SupplierParts ≠ π(Supplier, Part) ⨝ π(Supplier, Project) ⨝ π(Part, Project)
• When Does Join Dependency Hold?
• Let’s say the data was like this:
Supplier Part Project
S1 P1 J1
S1 P2 J1
S1 P1 J2
S1 P2 J2

• In this case, every Supplier-Part-Project combination can be built from the 3

projections, and:
• Original = R1 ⨝ R2 ⨝ R3
• So here, the join dependency holds, and this table can be decomposed
without loss.
60
• Summary
• A join dependency means: the original table = the join of its
projections.
• It’s central to Fifth Normal Form (5NF).
• If joining projections introduces wrong or extra rows → join
dependency does NOT hold.
• Use it when you split complex many-to-many relationships but still
want to preserve original data accurately.

61
 Fifth Normal Form (5NF)
A table is in Fifth Normal Form (5NF), also called Project-Join Normal Form (PJNF), if:
• It is already in BCNF.
• It removes join dependencies to eliminate redundancy while preserving all necessary data.

Example:

❌ Issue:
• The data seems correct, but redundancy exists because each Student_ID is independently related to both Course
and Instructor.

62
Fifth Normal Form (5NF)
• Converting to 5NF
✅ Break into three smaller tables to remove join dependency:

63
Thank You!!

64