Database Management System

Week 04

Relational Model
Engr. Rashid Farid Chishti
http://youtube.com/rfchishti
http://sites.google.com/site/chis
hti International Islamic University H-10, Islamabad, Pakistan
Learning Objectives
 Understand the relational model and its importance in DBMS
 Learn key concepts like relational schema, keys, and constraints
What is a Relational Model ?
 The Relational Model is a way to structure and manage data in a database by
organizing it into tables (relations).
 Converts the ER Diagram into tables (relations) with attributes.
 It was introduced by E.F. Codd in 1970 and is the foundation of most modern
database systems.
 Relational Model is the most widely used model.
 In this model, the data is maintained in the form of a two-dimensional table.
 All the information is stored in the form of row and columns.
 The basic structure of a relational model is tables.
 So, the tables are also called relations in the relational model.
Relational Model
 Purpose: Organizes data into tables (relations) with rows and columns.
 Focus: Relationships between tables using keys.
 Example: A university database with tables like Students, Courses, and Enrollments.
 Key Features:
 Uses tables, primary keys, foreign keys, and normalization.

 Supports SQL for querying.

 Most widely used model.

 DBMS: MySQL, PostgreSQL, Oracle,

SQL Server.
Relational Model Concepts
 Consider a relation STUDENT with attributes ROLL_NO, NAME, ADDRESS, PHONE and AGE
shown in Table 1

Roll_Number Name Address Phone Age

1 Ahmed Khan 123 Main Street, Karachi 0300-1234567 20
2 Fatima Ahmed 456 Elm Street, Lahore 0311-2345678 22
3 Ali Hassan 789 Oak Street, Islamabad 0322-3456789 21
4 Ayesha Malik 101 Pine Street, Faisalabad 0333-4567890 19
5 Usman Riaz 202 Maple Street, Peshawar 0344-5678901 23
Key Concepts of the Relational Model
Key Concepts of the Relational Model
1. Relation (Table)
 A table represents an entity or a relationship between entities. Each table has a unique

name. Tables are composed of rows (tuples) and columns (attributes).

2. Tuple (Row / Record)
 Each row in the relation (Table) is known as tuple.

 Each row contains data about a specific instance of the entity.

3. Relation Instance
 The set of tuples of a relation at a particular instance of time is called as relation

instance. Example: STUDENT at a particular time. It can change whenever there is

insertion, deletion or updating in the database.
4. Attribute (Column / Field)
 A property or characteristic of the entity, represented as a column in the table.

 Example: ROLL_NO, NAME, ADDRESS, PHONE, AGE in STUDENT Table

Key Concepts of the Relational Model
5. Domain
 The set of allowable values for an attribute (e.g., Age can have values from 1 to 100).

6. Relationships:
 One-to-One (1:1): One entity is related to one entity in another table.

 One-to-Many (1:M)

 Many-to-Many (M:N)

7. Primary Key (PK)

 A primary key is an attribute (or a combination of attributes) that uniquely identifies

each tuple (row) in a relation. It ensures that no two rows have the same value for this
attribute. Example: StudentID in the STUDENT table.
8. Foreign Key (FK)
 An attribute in one table that references the primary key of another table, establishing

relationships between tables.

Key Concepts of the Relational Model
9. Degree
 The number of attributes in a table (e.g., a table with 4 columns has degree 4).

10. Cardinality
 The number of tuples (rows) in a table.

11. NULL Values

 The value which is not known or unavailable is called NULL value. It is represented by

blank space. Example: A student record having no phone number in a STUDENT table.
12. Relational Schema
 The structure of the database, defining tables, attributes, and relationships.

 A relation schema represents name of the relation with its attributes.

 Example: STUDENT (ROLL_NO, NAME, ADDRESS, PHONE and AGE) is relation schema for

STUDENT.
Example of a Relational Model
Students Table Courses Table
Student_ID Name Age Major Course_ID Course_Name Credits
101 Alice 22 CS CS101 Databases 3
102 Bob 24 Math MT202 Algebra 3 Enrollments Table
103 John 23 CS (Relationship Table)
Student_ID Course_ID Grade
101 CS101 A
102 MT202 B+

 Relationships:
 Many-to-Many (M:N)
 Many students can enroll in many courses
Properties of Relations
 Name of relation is distinct from all other relations.
 Each relation cell contains exactly one atomic (single) value.
 Each attribute contains a distinct name.
 Tuple has no duplicate value.
 Order of tuple can have a different sequence.
Operations in Relational Model
 Insert Operation
 The insert operation gives values of the attribute for a new tuple which should be

inserted into a relation.

 Update Operation
 You can see that in the below-given relation table CustomerName= 'Apple' is updated

from Inactive to Active.

Operations in Relational Model
 Delete Operation
 To specify deletion, a condition on the attributes of the relation selects the tuple to be

deleted. Example: CustomerName = “Apple” is deleted from the table

 Select Operation
 Select a specific values. Example: CustomerName= ‘Amazon' is selected.
Relational Schema
 A Relational Schema is the blueprint of a relational database. It defines how
data is organized and how relationships between data are maintained.
 It describes the structure of tables (relations), the attributes (columns) in each
table, and the constraints applied to the data.
 Key Components of a Relational Schema:
 Tables (Relations): Represents entities or relationships.
 Attributes (Columns): Represents the properties or fields of an entity.
 Tuples (Rows): Represents records or data entries in a table.
 Primary Key: Uniquely identifies each tuple in a table.
 Foreign Key: Establishes relationships between tables by referring to the primary key of
another table.
 Constraints: Rules like NOT NULL, UNIQUE, CHECK, and DEFAULT that maintain data
integrity.
Relational Schema: Example
 Imagine a university database with two entities: Students and Courses.
Customer Order Product
PK ID Customer_ID PK ID
Name Product_ID Quantity
Phone Order_Date Product_Type
Address Order_Status

 Relational Schema:
 Customer(ID, Name, Phone, Address)
 Product(ID, Quantity, Product_Type)
 Order(Student_ID, Product_ID, Order_Date, Order_Status)
Relational Schema: Example
 Primary Keys:
 ID for Customer
 ID for Product
 Composite key (Student_ID, Course_ID) for Order
 Foreign Keys:
 Student_ID in Order references ID in Customer
 Product_ID in Order references ID in Product
Relational Schema: How it Works
 The schema defines the structure but does not store data directly.
 SQL is used to implement the schema, create tables, and manage data.
 The schema ensures data consistency by enforcing relationships between
tables. CREATE TABLE COURSE (
CourseID INT PRIMARY KEY,
Title VARCHAR(100) NOT NULL,
Credits INT CHECK (Credits > CREATE TABLE STUDENT (
0) StudentID INT PRIMARY
); KEY,
CREATE TABLE ENROLLMENT ( Name VARCHAR(100) NOT
StudentID INT, NULL,
CourseID INT, Age INT CHECK (Age >=
Grade CHAR(1), 18),
PRIMARY KEY (StudentID, CourseID), Major VARCHAR(50)
FOREIGN KEY (StudentID) REFERENCES STUDENT(StudentID) ON DELETE
);
CASCADE,
FOREIGN KEY (CourseID) REFERENCES COURSE(CourseID) ON DELETE
CASCADE
Relational Schema: How it Works
 Example Data Insertion:
INSERT INTO STUDENT VALUES (101, 'Alice Johnson', 20, 'Computer
Science');
INSERT INTO COURSE VALUES (301, 'Database Systems', 3);
INSERT INTO ENROLLMENT VALUES (101, 301, 'A');
 Query Example:
SELECT s.Name, c.Title, e.Grade
FROM STUDENT s
JOIN ENROLLMENT e ON s.StudentID = e.StudentID
JOIN COURSE c ON e.CourseID = c.CourseID;
Comparison of three Models
Feature ER Model Relational Model Relational Schema
Physical blueprint for database
Purpose Conceptual design of data Logical structure of data
implementation
Entities, attributes, and Tables (relations), rows (tuples), Table structures, columns, and
Focus constraints
relationships and columns (attributes)
ER Diagrams (Entities,
Representation Relations (Tables) Table definitions with attributes
Relationships)
Abstraction
High-level Mid-level Low-level
Level
Early stage (Conceptual Intermediate stage (Logical Final stage (Physical
Design Stage implementation)
design) design)
Database developers (SQL
Used By Database designers Database architects
coders)

Use Case Planning and early-stage Conceptualizing and structuring Defining tables for the DBMS.
design. data.
Levels of Abstraction
Feature ER Model Relational Model Relational Schema

Entity Names ✔ ✔

Attributes ✔ ✔

Entity Relationships ✔ ✔

Primary Keys ✔ ✔ ✔

Foreign Keys ✔ ✔

Tables Names ✔

Column Names ✔

Column Data Types ✔

How They Fit Together in Database Design:
 1. Start with ER Model (Conceptual Design):
 Identify entities, attributes, and relationships.
 Create an ER diagram representing the high-level structure.
 2. Convert to Relational Model (Logical Design):
 Translate ER diagrams into tables, keys, and relationships.
 3. Implement Relational Schema (Physical Design):
 Define SQL CREATE TABLE statements to implement the tables and constraints in the
database.
Example Workflow
 1. ER Model (Design Phase): CREATE TABLE COURSE(
CourseID INT PRIMARY
 Entity: STUDENT with attributes StudentID, Name, and Age. KEY,
 Relationship: ENROLLMENT links STUDENT to COURSE. Title VARCHAR(100)
);
 2. Relational Model (Logical Phase):
 Tables: STUDENT(StudentID, Name, Age), COURSE(CourseID, Title),
ENROLLMENT(StudentID, CourseID).
 3. Relational Schema (Implementation Phase):

CREATE TABLE STUDENT( CREATE TABLE ENROLLMENT (

StudentID INT PRIMARY StudentID INT,
KEY, CourseID INT,
Name VARCHAR(100), PRIMARY KEY (StudentID, CourseID),
Age INT FOREIGN KEY (StudentID) REFERENCES
); STUDENT(StudentID),
FOREIGN KEY (CourseID) REFERENCES
COURSE(CourseID)
Advantages of using Relational Model
 The Relational Model in databases offers several advantages, making it a widely used and
preferred approach for data management. Here are some key benefits:
 Simplicity & Ease of Use
 Uses tables (relations), which are intuitive and easy to understand.

 Data is represented in rows and columns, making it straightforward to query and

manipulate.
 Structural Independence
 Changes in database schema (such as adding or modifying columns) do not affect

applications using the database.

 Provides flexibility in evolving the database structure.

 Data Integrity & Accuracy

 Supports integrity constraints (e.g., primary keys, foreign keys, and unique constraints) to

maintain data consistency. Ensures referential integrity, preventing orphan records and
maintaining valid relationships.
Advantages of using Relational Model
 Reduced Data Redundancy
 Normalization techniques eliminate data duplication, improving storage efficiency.

 Reducing redundancy helps maintain consistency across records.

 Data Security
 Provides access control mechanisms, ensuring only authorized users can access or

modify data. Allows implementation of different privileges for different users.

 Flexibility in Querying (SQL Support)
 Supports Structured Query Language (SQL), which enables complex queries, filtering, and

data manipulation. SQL makes it easier to retrieve and update data efficiently.
 Multi-User Support & Concurrency Control
 Allows multiple users to access and manipulate the database simultaneously.

 Implements transactions with ACID (Atomicity, Consistency, Isolation, Durability)

properties, ensuring reliability.

Advantages of using Relational Model
 Data Consistency
 Enforces constraints and rules to maintain correct and reliable data.

 Ensures that changes made by one user do not negatively impact others.

 Scalability & Performance Optimization

 Can handle large datasets and complex relationships efficiently.

 Indexing, query optimization, and partitioning techniques enhance performance.

 Standardization & Portability

 Relational databases follow ANSI/ISO standards, making them compatible across

different platforms.
 Popular RDBMSs like MySQL, PostgreSQL, Oracle, and SQL Server support the relational

model, ensuring widespread adoption.

Disadvantages of using Relational Model
 1. Complexity & Performance Overhead
 Requires complex schema design (e.g., normalization) to ensure efficiency.

 Queries involving multiple joins can be slow and resource-intensive.

 Performance may degrade for large-scale applications with millions of transactions.

 2. Storage & Hardware Requirements

 Requires more storage space due to indexes, constraints, and relationships.

 High-performance relational databases may need powerful hardware for efficient

operations.
 3. Scalability Challenges
 Vertical Scaling (adding more resources to a single server) is common but has limits.

 Horizontal Scaling (distributing data across multiple servers) is complex compared to

NoSQL databases.
Disadvantages of using Relational Model
 4. Rigid Schema Structure
 Changes in the schema (e.g., adding/removing columns) can be difficult and impact

existing applications.
 Not ideal for dynamic or semi-structured data (e.g., JSON, XML).

 5. Complexity in Handling Unstructured Data

 Not well-suited for big data, multimedia, or document-based storage.

 No built-in support for hierarchical or graph-like relationships (Graph Databases perform

better here).
 6. High Development & Maintenance Cost
 Requires specialized expertise for database design, optimization, and administration.

 Regular backups, indexing, query tuning, and security management add to maintenance

costs.
Disadvantages of using Relational Model
 7. ACID Compliance Overhead
 While ACID properties ensure consistency, they can introduce latency in distributed

systems.
 Eventual consistency (used in NoSQL) is sometimes preferred for high-speed applications.

 8. Not Ideal for Real-Time Applications

 Complex joins and integrity constraints can slow down real-time data processing.

 NoSQL databases are often preferred for real-time analytics and IoT applications.
ER Diagram
Relational Diagram
Attributes
Relationships
Cardinality
ER Diagram Example Using Draw.IO
ER Diagram Example Using Draw.IO
Roles in Relationships
Symbol Meaning
Non Identifying
Relationship
Identifying Relationship

One Identifying

Many Identifying

One Identifying

Many Identifying
Roles in Relationships
Roles in Relationships
Business Rule 1
 An employee can have 0,1 or several phone numbers
 They may or may not have a telephone number

Employee Phone
ID Phone_Number
First_Name Employee_ID
Last_Name Phone_Type
City Primary_OR_Secondry
Street
House
Email
Business Rule 2
 There are finite number of phone number combinations that exist.
 Over time different employee can have same phone number, each a different
time.
Phone
Phone_Number
Employee_ID
Phone_Type
Primary_OR_Secondry
Business Rule 3
 An employee can be paid either hourly or by a yearly salary. Depending on
how they are paid, we need to collect specific information that applies only to
that type of employee.

Employee Hourly_Employee
ID Employee_ID
First_Name Hourly_Rate
Last_Name Full_Time_OR_Part_Time
City
Salary_Employee
Street
Employee_ID
House
Monthly_Salary
Email
Business Rule 4
 An employee can be assigned to many projects, however a single project can
have multiple employees assigned to it.
Employee Project
Assignment
ID ID
Employee_ID
First_Name Name
Project_ID
Last_Name Description
Assigned_On
City Start_Date
Street End_Date
House
Email
MySQL Sample Database
MySQL Sample Database
MySQL Sample Database
Converting ER Model to Relational Schema
 Steps:
1. Convert entities to tables
2. Convert attributes to columns
3. Define primary and foreign keys
4. Represent relationships through foreign keys
 Example:
 Entity: Student (StudentID, Name) → Table: Student

 Relationship: Enrolled (StudentID, CourseID)

Converting ER Model to Table
 Rule 1: Strong Entity Set with Simple Attribute
 Attributes of the table will be the attributes of the entity set.

 The primary key of the table will be the key attribute of the entity set.

Roll_No Name Gender

Schema: Student(Roll_No, Name, Gender)

Converting ER Model to Table
 Rule 2: For Strong Entity Set with Composite Attribute
 A strong entity set with any number of composite attributes will require only one table in

relational model.
 During conversion, simple attributes of the composite attributes are taken into account

and not composite attribute itself.

Roll_No First_Name Last_Name Gender City Street House

Schema: Student(Roll_No, First_Name,

Last_Name, Gender, City, Street, House)
Converting ER Model to Table
 Rule 3: For Strong Entity Set with Multi Valued Attribute
 A strong entity set with any number of multivalued attributes will require two tables in

relational model.
 One table will contain all the simple attributes with the primary key.

 Other table will contain the primary key and all the multi valued attributes.

Roll_No Name Roll_No Mobile_No

Converting ER Model to Table
 Rule 4: Translating Relationship Set into a Table
 Attributes of the table are

 Primary Key attributes of the participating entity set.

 Its own descriptive attributes if any.

 Set of non-descriptive attributes will be the primary key.

Emp_No Dept_ID Since

Schema: Works_In (Emp_ID, Dept_ID, Since)

Converting ER Model to Table
 Rule 5: For Binary Relationships with Cardinality Ratios
 Case 1: For binary relationship with Cardinality Constraint M:N

Here 3 tables will be

required
M N 1. A (a1, a2)
2. B (b1, b2)
3. R (a1, b1)

 Case 2: For binary relationship with Cardinality Constraint 1:N

Here 2 tables will be

required
1 N 1. A (a1, a2)
2. BR (a1, b1, b2)
Converting ER Model to Table
 Rule 5: For Binary Relationships with Cardinality Ratios
 Case 3: For binary relationship with Cardinality Constraint M:1

Here 2 tables will be

required
M 1 1. AR (a1, a2, b1)
2. B (b1, b2)

 Case 4: For binary relationship with Cardinality Constraint 1:1

Way 1
1. AR (a1, a2, b1)
2. B (b1, b2)

1 1 Way 2
3. A (a1, a2)
4. BR (a1, b1, b2)
Converting ER Diagram to Table
Relational Diagram for University Database