Database Management System (DBMS)

Data Modeling in DBMS

Data modeling is the process of creating a conceptual representation of data and
its relationships. It helps in designing the database structure before
implementation. One of the most widely used data modeling techniques is the
Entity-Relationship (ER) Model, which provides a high-level view of data and its
interactions.

The ER Model was introduced by Peter Chen in 1976 and is primarily used in the
conceptual design phase of databases.

ER Model Concepts
The Entity-Relationship (ER) Model consists of several fundamental concepts:

2.1 Entity
An Entity is an object in the real world that can be identified uniquely. It
represents a real-world object that has attributes.

Types of Entities:
1. Strong Entity: An entity that has a primary key and exists independently.

2. Weak Entity: An entity that cannot exist without a strong entity and does
not have a primary key.

Example: In a university database, "Student" and "Course" can be considered

strong entities, whereas "Enrollment" (which depends on both students and
courses) is a weak entity.
2.2 Attribute
Attributes define the properties of an entity.

Types of Attributes:
• Simple Attribute: Cannot be divided further (e.g., Name, Age).

• Composite Attribute: Can be divided into sub-parts (e.g., Address → Street,

City, State).

• Derived Attribute: Derived from other attributes (e.g., Age from Date of
Birth).

• Multivalued Attribute: Can have multiple values (e.g., Phone numbers).

2.3 Relationship
A relationship is an association between two or more entities.

Example: "A student enrolls in a course."

2.4 Cardinality
Cardinality defines the number of entity instances that can be associated with
another entity.

• One-to-One (1:1): A person has one passport.

• One-to-Many (1:M): A teacher teaches multiple students.

• Many-to-Many (M:N): Students enroll in multiple courses.

 Notation of ER Diagram
ER diagrams use symbols to represent entities, attributes, and
relationships:

Symbol Meaning

Rectangle Entity

Ellipse Attribute

Diamond Relationship

Line Connection between entities and attributes

Double Rectangle Weak Entity

Double Ellipse Multivalued Attribute

Dashed Ellipse Derived Attribute

Mapping Constraints in ER Model
Mapping constraints define rules for relationships between entities. They
determine how many instances of one entity can be associated with
instances of another entity.

Types of Mapping Constraints -

Mapping Description Example
Constraint

One-to- Each entity in A is A CEO manages one

One (1:1) related to at most one company, and a
entity in B, and vice company has one
versa. CEO.

One-to- One entity in A can be A department has

Many related to multiple multiple employees,
(1:M) entities in B, but each but each employee
entity in B is related to belongs to only one
only one entity in A. department.

Many-to- Multiple entities in A Students enroll in

Many can be related to multiple courses, and
(M:N) multiple entities in B. each course has
multiple students.
ER Diagram Representation of Mapping Constraints:
One-to-One (1:1) Example: CEO and Company

One-to-Many (1:M) Example: Department and Employee

Many-to-Many (M:N) Example: Student and Course

 Mapping Constraints in Tables
1:1 Mapping Example (CEO - Company)

1:M Mapping Example (Department - Employee)

M:N Mapping Example (Student - Course)

 Keys in ER Model
Keys uniquely identify records in a table. Different types of keys play
important roles in database integrity and structure.

Super Key
A Super Key is a set of one or more attributes that can uniquely identify an
entity.

Example:

STUDENT (Student_ID, Name, Age, Course_ID)

Super Key: {Student_ID}, {Student_ID, Name}, {Student_ID, Course_ID}

Candidate Key
A Candidate Key is a minimal super key, meaning it has no unnecessary
attributes.

Example:

Candidate Keys: {Student_ID}, {Name, Course_ID}

Primary Key
A Primary Key is a candidate key selected to uniquely identify records.

Example:

CREATE TABLE Student (

Student_ID INT PRIMARY KEY,

Name VARCHAR(50),

Age INT

);
Foreign Key
A Foreign Key is an attribute in one table that refers to the primary key of
another table.

Example:

CREATE TABLE Enrolls (

Student_ID INT,

Course_ID INT,

FOREIGN KEY (Student_ID) REFERENCES Student(Student_ID)

);

Composite Key
A Composite Key consists of multiple attributes that together uniquely
identify a record.

Example:

CREATE TABLE Enrollment (

Student_ID INT,

Course_ID INT,

PRIMARY KEY (Student_ID, Course_ID)

);

Alternate Key
An Alternate Key is a candidate key that is not chosen as the primary key.

Unique Key
A Unique Key ensures uniqueness but allows null values.
Example:

CREATE TABLE Employee (

Emp_ID INT PRIMARY KEY,

Email VARCHAR(100) UNIQUE

);

----------------------------------------------------------------------------------------------

Generalization and Aggregation in ER Model

Generalization
Generalization is the process of combining multiple lower-level entities
into a single higher-level entity. It is a bottom-up approach in which
common attributes from multiple entities are generalized into a parent
entity.

Example:

Consider Car, Truck, and Bike entities. They share common attributes like
Vehicle_ID and Brand, so we generalize them into a higher entity called
Vehicle.

ER Diagram Representation:
Table Representation:

Aggregation
Aggregation is an abstraction in which a relationship itself is treated as an
entity. This is useful when an entity participates in multiple relationships
and needs to be considered as a higher-level entity.

Example:

Consider a Project entity that is managed by an Employee and is

sponsored by a Company. Here, the "Manages" relationship is treated as
an entity and is linked with the Company.
ER Diagram Representation:

Table Representation:
Reduction of ER Diagram to Tables in DBMS
Introduction
The ER Model provides a conceptual framework for designing databases.
However, to implement the database, the ER diagram must be converted
into relational tables. This process is called Reduction of ER Diagram to
Tables (Schema Conversion).

Steps for Reducing ER Diagram to Tables

1. Mapping Strong Entities

A strong entity has a primary key and does not depend on any other entity.
Each strong entity is converted into a table with attributes as columns.

Example: Consider the entity Student

ER Diagram Representation:
Mapping Weak Entities
A weak entity depends on a strong entity and lacks a primary key. A
foreign key is added to reference the strong entity.

Example: Consider Dependent as a weak entity related to Employee

ER Diagram Representation:

Table Representation:
Mapping Relationships
Relationships are represented using foreign keys. Depending on the
cardinality (1:1, 1:M, M:N), we use different methods.

(a) One-to-One Relationship (1:1)

A foreign key is placed in either table to link the relationship.

Example: A Person has one Passport

ER Diagram Representation:

Table Representation:
(b) One-to-Many Relationship (1:M)
The foreign key is placed in the "many" side table.

Example: A Department has multiple Employees

ER Diagram Representation:

Table Representation:

CREATE TABLE Department (

Dept_ID INT PRIMARY KEY,

Dept_Name VARCHAR(50)

);

CREATE TABLE Employee (

Emp_ID INT PRIMARY KEY,

Name VARCHAR(50),

Dept_ID INT,

FOREIGN KEY (Dept_ID) REFERENCES Department(Dept_ID)

);
(c) Many-to-Many Relationship (M:N)
A new table (junction table) is created to store the relationship.

Example: Students enroll in Courses

ER Diagram Representation:

Table Representation:
CREATE TABLE Student (

Student_ID INT PRIMARY KEY,

Name VARCHAR(50)

);

CREATE TABLE Course (

Course_ID INT PRIMARY KEY,

Course_Name VARCHAR(50)

);
CREATE TABLE Enrolls (

Student_ID INT,

Course_ID INT,

PRIMARY KEY (Student_ID, Course_ID),

FOREIGN KEY (Student_ID) REFERENCES Student(Student_ID),

FOREIGN KEY (Course_ID) REFERENCES Course(Course_ID)

);

Mapping Multivalued Attributes

Multivalued attributes require a separate table to store multiple values for
each entity.

Example: A Person can have multiple Phone Numbers

ER Diagram Representation:
Table Representation:
CREATE TABLE Person (

Person_ID INT PRIMARY KEY,

Name VARCHAR(50)

);

CREATE TABLE Phone_Number (

Person_ID INT,

Phone VARCHAR(15),

PRIMARY KEY (Person_ID, Phone),

FOREIGN KEY (Person_ID) REFERENCES Person(Person_ID)

);

Mapping Generalization and Specialization

For Generalization, a single table is used to store common attributes, while
sub-entities have separate tables.

Example: Car, Truck, Bike generalizing to Vehicle

ER Diagram Representation:

Table Representation:

CREATE TABLE Vehicle (

Vehicle_ID INT PRIMARY KEY,

Brand VARCHAR(50)

);

CREATE TABLE Car (

Vehicle_ID INT PRIMARY KEY,

Car_Type VARCHAR(50),

FOREIGN KEY (Vehicle_ID) REFERENCES Vehicle(Vehicle_ID)

);
Introduction to the Extended ER Model
The Extended Entity-Relationship (EER) Model is an enhanced version of
the traditional ER model that introduces additional concepts like
Specialization, Generalization, Aggregation, and Subclasses. It provides a
more detailed representation of complex real-world applications.

Why Use EER Model?

✔ It extends the ER model to capture more detailed relationships.

✔ It supports inheritance, making it easier to represent hierarchical
relationships.
✔ It is used in object-oriented databases and complex database systems.
 Introduction to Higher-Degree Relationships
In the ER model, a relationship defines how entities are associated with
one another. Most commonly, relationships involve two entities (binary
relationships). However, some scenarios require more than two entities in
a relationship.

What is a Higher-Degree Relationship?

A higher-degree relationship involves more than two entities in a single
relationship.

• Binary Relationship (Degree = 2) → Between two entities (e.g., Student -

Enrolls - Course)

• Ternary Relationship (Degree = 3) → Between three entities (e.g., Doctor -

Treats - Patient - Hospital)

• N-ary Relationship (Degree > 3) → Involves N entities in a single

relationship.

Why Use Higher-Degree Relationships?

✔ Helps in modeling complex real-world scenarios
✔ Reduces redundant relationships
✔ Represents multi-entity interactions
 Types of Higher-Degree Relationships

1. Ternary Relationship (Degree = 3)

A Ternary Relationship involves three entities in a single relationship.

Example:
Consider a Supplier supplying a Product to a Customer.

• A Supplier provides a Product

• A Customer buys a Product

• The Supplier and Customer interact through the Product

2. Quaternary Relationship (Degree = 4)

A Quaternary Relationship involves four entities in a single relationship.

Example:
A Doctor is assigned to a Patient in a Hospital under a specific Treatment.

• A Doctor treats a Patient

• A Hospital hosts the Treatment

• The Patient receives Treatment under Doctor’s supervision

3. N-ary Relationship (Degree > 4)

When a relationship involves more than four entities, it is called an N-ary
Relationship.

• These relationships are complex and often broken into smaller

relationships.

• It is difficult to implement directly in relational databases.

Example:
A University has multiple Professors who teach various Courses that are
taken by Students under a specific Department.
Difference Between Binary and Higher-Degree Relationships