Relational Model: Introduction to relational model, concepts of domain, attribute, tuple,

relation, importance of null values, constraints (Domain, Key constraints, integrity constraints)
and their importance, Relational Algebra (select and project) .
Entity Relationship Model: Introduction, Representation of entities, attributes, entity set,
relationship, relationship set, constraints, extended features of ER model, conversion of ER
diagrams to tables

Relational Model in DBMS

After designing the conceptual model of the Database using ER diagram, we need to convert the
conceptual model into a relational model which can be implemented using any RDBMS
language like Oracle SQL, MySQL, etc

What is the Relational Model?

The relational model represents how data is stored in Relational Databases. A relational
database stores data in the form of relations (tables). Consider a relation STUDENT with
attributes ROLL_NO, NAME, ADDRESS, PHONE, and AGE shown
Student

ROLL_NO NAME ADDRESS PHONE AGE

1 RAM DELHI 9455123451 18

2 RAMESH GURGAON 9652431543 18

3 SUJIT ROHTAK 9156253131 20

4 SURESH DELHI 18

Table-A database table is a structure that organises data into rows and columns
row represent record and column represent attribute
 Attribute: Attributes are the properties that define a relation. e.g.; ROLL_NO, NAME
Domain: All attributes have some pre-defined scope and value which is called attribute
domain.
Relation Schema: A relation schema represents the name of the relation with its attributes.
e.g.; STUDENT (ROLL_NO, NAME, ADDRESS, PHONE, and AGE) is the relation schema for
STUDENT.
If a schema has more than 1 relation, it is called Relational Schema.

Tuple: Each row in the relation is known as a tuple. The above relation contains 4 tuples, one
of which is shown as:

1 RAM DELHI 9455123451 18

Relation Instance: The set of tuples of a relation at a particular instance of time is called a
relation instance. Table 1 shows the relation instance of STUDENT at a particular time. It can
change whenever there is an insertion, deletion, or update in the database.

Cardinality: The number of tuples in a relation is known as cardinality. The STUDENT relation
defined above has cardinality 4.

Degree: The number of attributes in the relation is known as the degree of the relation. The
STUDENT relation defined above has degree 5.

Column: The column represents the set of values for a particular attribute. The column
ROLL_NO is extracted from the relation STUDENT. Eg ROLL_NO

NULL Values: The value which is not known or unavailable is called a NULL value. It is
represented by blank space. e.g.; PHONE of STUDENT having ROLL_NO 4 is NULL.
Importance of NULL value:

● It is important to understand that a NULL value is different from a zero value.

● A NULL value is used to represent a missing value, but that it usually has one of three
different interpretations:
○ The value unknown (value exists but is not known)
○ Value not available (exists but is purposely withheld)
○ Attribute not applicable (undefined for this tuple)
● It is often not possible to determine which of the meanings is intended. Hence, SQL
does not distinguish between the different meanings of NULL.

Constraints in Relational Model:

While designing the Relational Model, we define some conditions which must hold for data
present in the database are called Constraints. These constraints are checked before
performing any operation (insertion, deletion, and updation ) in the database. If there is a
violation of any of the constraints, the operation will fail.

Domain Constraints: These are attribute-level constraints. An attribute can only take values
that lie inside the domain range. e.g; If a constraint AGE>0 is applied to STUDENT relation,
inserting a negative value of AGE will result in failure.

Key Integrity: Every relation in the database should have at least one set of attributes that
defines a tuple uniquely. Those set of attributes is called keys. e.g.; ROLL_NO in STUDENT is a
key. No two students can have the same roll number. So a key has two properties:
● It should be unique for all tuples.
● It can’t have NULL values.
Referential Integrity: When one attribute of a relation can only take values from another
attribute of the same relation or any other relation, it is called referential integrity. Let us
suppose we have 2 relations
STUDENT

ROLL_NO NAME ADDRESS PHONE AGE BRANCH_CODE

1 RAM DELHI 9455123451 18 CS

2 RAMESH GURGAON 9652431543 18 CS

3 SUJIT ROHTAK 9156253131 20 ECE

4 SURESH DELHI 18 IT

BRANCH

BRANCH_CODE BRANCH_NAME

CS COMPUTER SCIENCE

IT INFORMATION TECHNOLOGY

ECE ELECTRONICS AND COMMUNICATION ENGINEERING

CV CIVIL ENGINEERING

BRANCH_CODE of STUDENT can only take the values which are present in BRANCH_CODE of
BRANCH which is called referential integrity constraint. The relation which is referencing
another relation is called REFERENCING RELATION (STUDENT in this case) and the relation to
which other relations refer is called REFERENCED RELATION(BRANCH in this case).
INTEGRITY CONSTRAINTS/CONSTRAINTS
- A constraint is a condition or check applicable on a field(column) or set of
fields(columns).
- Common types of constraints include :

NOT NULL CONSTRAINT

By default, a column can hold NULL. It you not want to allow NULL value in a column, then NOT
NULL constraint must be applied on that column.

E.g.

CREATE TABLE Customer

(SID integer NOT NULL , Last_Name varchar(30) First_Name varchar(30) NOT NULL ,) ;

Columns SID and Last_Name cannot include NULL, while First_Name can include NULL.
An attempt to execute the following SQL statement,

INSERT INTO Customer

VALUES (NULL , ‘Kumar’ , ‘Ajay’);
will result in an error because this will lead to column SID being NULL, which violates the NOT
NULL constraint on that column.

DEFAULT CONSTARINT

The DEFAULT constraint provides a default value to a column when the INSERT INTO
statement does not provide a specific value.
E.g.

CREATE TABLE Student ( Student_ID integer ,Name varchar(30) ,Score integer DEFAULT
80);

When following SQL statement is executed on table created above:

INSERT INTO Student

no value has been provided for score field.
VALUES (10 , ‘Ravi’ );
Then table Student looks like the following:
Student_ID Name Score score field has got the default value
10 Ravi 80
UNIQUE CONSTRAINT
- The UNIQUE constraint ensures that all values in a column are distinct. In other words,
no two rows can hold the same value for a column with UNIQUE constraint.

e.g.
CREATE TABLE Customer (SID integer Unique , Last_Name varchar(30) , First_Name
varchar(30) ) ;

Column SID has a unique constraint, and hence cannot include duplicate values. So, if the table
already contains the following rows :

SID Last_Name First_Name

1 Kumar Ravi
2 Sharma Ajay
3 Devi Raj

The executing the following SQL statement,

INSERT INTO Customer
VALUES (‘3’ , ‘Cyrus‘ , ‘Grace’) ;
will result in an error because the value 3 already exist in the SID column, thus trying to insert
another row with that value violates the UNIQUE constraint.

CHECK CONSTRAINT
- The CHECK constraint ensures that all values in a column satisfy certain conditions.
Once defined, the table will only insert a new row or update an existing row if the new value
satisfies the CHECK constraint.

e.g.
CREATE TABLE Customer( SID integer CHECK (SID > 0),Last_Name varchar(30) ,
First_Name varchar(30) ) ;

So, attempting to execute the following statement :

INSERT INTO Customer VALUES (-2 , ‘Kapoor’ , ‘Raj’);

will result in an error because the values for SID must be greater than 0.

PRIMARY KEY CONSTRAINT

- A primary key is used to identify each row in a table. A primary key can consist of one or
more fields(column) on a table. When multiple fields are used as a primary key, they are called a
composite key.

- You can define a primary key in CREATE TABLE command through keywords PRIMARY
KEY.
e.g.
CREATE TABLE Customer
(SID integer NOT NULL PRIMARY KEY, Last_Name varchar(30) , First_Name varchar(30)) ;

Or
CREATE TABLE Customer ( SID integer,
Last_Name varchar(30) , First_Name varchar(30), PRIMARY KEY (SID) ) ;

- The latter way is useful if you want to specify a composite primary key, e.g.

CREATE TABLE Customer( Branch integer NOT NULL, SID integer NOT NULL ,
Last_Name varchar(30) , First_Name varchar(30),PRIMARY KEY (Branch , SID) ) ;

FOREIGN KEY CONSTRAINT

-Foreign key is a non key column of a table (child table) that draws its values from primary key
of another table(parent table).
-The table in which a foreign key is defined is called a referencing table or child table. A table to
which a foreign key points is called referenced table or parent table.

Child Table

ROLL_NO MARKS
1 55
2 83
3 90

Here column Roll_No is a foreign key in table SCORE(Child Table) and it is drawing its values
from Primary key (ROLL_NO) of STUDENT table.(Parent Key).

CREATE TABLE STUDENT

(ROLL_NO integer NOT NULL PRIMARY KEY , NAME VARCHAR(30) ,CLASS VARCHAR(3) );

CREATE TABLE SCORE( ROLL_NO integer ,MARKS integer ,

FOREIGN KEY(ROLL_NO) REFERNCES STUDENT(ROLL_NO) ) ;

* Foreign key is always defined in the child table.

Syntax for using foreign key

FOREIGN KEY(column name) REFERENCES Parent_Table(PK of Parent Table);

REFERENCING ACTIONS

Referencing action with ON DELETE clause determines what to do in case of a DELETE occurs
in the parent table. Referencing action with ON UPDATE clause determines what to do in case
of a UPDATE occurs in the parent table.

Actions:
1. CASCADE : This action states that if a DELETE or UPDATE operation affects a row
from the parent table, then automatically delete or update the matching rows in the child table
i.e., cascade the action to child table.
2. SET NULL : This action states that if a DELETE or UPDATE operation affects a row
from the parent table, then set the foreign key column in the child table to NULL.
3. NO ACTION : Any attempt for DELETE or UPDATE in parent table is not allowed.
4. RESTRICT : This action rejects the DELETE or UPDATE operation for the parent table.
To illustrate cascading actions with table contents, let's consider two tables: Departments (the
parent table) and Employees (the child table). We'll demonstrate the effects of ON DELETE
CASCADE and ON UPDATE CASCADE with actual data.

1. Table Creation

-- Parent Table: Departments

CREATE TABLE Departments (
DepartmentID INT PRIMARY KEY,
DepartmentName VARCHAR(100)
);

-- Child Table: Employees

CREATE TABLE Employees (EmployeeID INT PRIMARY KEY,EmployeeName
VARCHAR(100), DepartmentID INT,
FOREIGN KEY (DepartmentID) REFERENCES Departments(DepartmentID)
ON DELETE CASCADE
ON UPDATE CASCADE);

2. Initial Data in Tables

Let's populate these tables with some data.

sql
Copy code
-- Inserting data into Departments
INSERT INTO Departments (DepartmentID, DepartmentName) VALUES
(1, 'HR'),
(2, 'Finance'),
(3, 'IT');

-- Inserting data into Employees

INSERT INTO Employees (EmployeeID, EmployeeName, DepartmentID) VALUES
(101, 'Alice', 1),
(102, 'Bob', 2),
(103, 'Charlie', 3),
(104, 'Diana', 1);
Table Contents Before Cascading Actions

Departments Table:Employees Table:

DepartmentID DepartmentName

1 HR

2 Finance

3 IT

EmployeeID EmployeeNam DepartmentID

e

101 Alice 1

102 Bob 2

103 Charlie 3

104 Diana 1

3. ON DELETE CASCADE Example

When a row in the parent table (the table with the primary key) is deleted, the corresponding
rows in the child table (the table with the foreign key) are automatically deleted as well.

-- Deleting a department
DELETE FROM Departments WHERE DepartmentID = 1;

Table Contents After ON DELETE CASCADE

Departments Table:

DepartmentID DepartmentName

2 Finance

3 IT
Employees Table:

EmployeeID EmployeeName DepartmentID

102 Bob 2

103 Charlie 3

● Result: Both Alice and Diana, who were part of the HR department (DepartmentID
= 1), were automatically deleted from the Employees table.

4. ON UPDATE CASCADE Example

When the value of a primary key in the parent table is updated, the corresponding foreign key
values in the child table are automatically updated to match the new primary key value.

sql
Copy code
-- Updating a department ID
UPDATE Departments SET DepartmentID = 4 WHERE DepartmentID = 2;

Table Contents After ON UPDATE CASCADE

Departments Table:

DepartmentID DepartmentName

3 IT

4 Finance

Employees Table:

EmployeeID EmployeeName DepartmentID

102 Bob 4

103 Charlie 3

● Result: The DepartmentID for Finance was changed from 2 to 4 in the

Departments table, and this change was automatically reflected in the Employees
table for Bob, who now has DepartmentID = 4.
 ON DELETE SET NULL

● Behavior: When a row in the parent table is deleted, the corresponding foreign key
values in the child table are set to NULL.

Example:

● CREATE TABLE Employees (EmployeeID INT PRIMARY KEY,EmployeeName

VARCHAR(100), DepartmentID INT,
FOREIGN KEY (DepartmentID)
REFERENCES Departments(DepartmentID) ON DELETE NULL);

Departments Table:

DELETE FROM Departments WHERE DepartmentID = 3;

DepartmentID DepartmentName

4 Finance

Employees Table:

EmployeeID EmployeeNam DepartmentID

e

102 Bob 4

103 Charlie NULL

Scenario:

● If a customer is deleted from the Customers table, the CustomerID in the Orders
table is set to NULL for all orders made by that customer.

—---------------------------------------------------------------------------------------------------------
Relational Algebra (select and project) .

Relational Algebra is a procedural query language. Relational algebra mainly provides a

theoretical foundation for relational databases and SQL

which takes instances of relations as input and yields instances of relations as output. It uses
operators to perform queries
It gives a step by step process to obtain the result of the query

he main purpose of using Relational Algebra is to define operators that transform one or more
input relations into an output relation

Fundamental Operators
These are the basic/fundamental operators used in Relational Algebra.
1. Selection (σ)

2. Projection (π)

3. Union(U)

4. Set Difference(-)

5. Set Intersection(∩)

6. Rename(ρ)

7. Cartesian Product(X)

Select Operation:

The select operation selects tuples that satisfy a given predicate.

It is denoted by sigma (σ).

Notation: σ p(r)
σ is used for selection prediction

r is used for relation

p is used as a propositional logic formula which may use connectors like: AND
OR and NOT. These relational can use as relational operators like =, ≠, ≥, <, >, ≤

For example: LOAN Relation

 BRANCH_NAME LOAN_NO AMOUNT

Downtown L-17 1000

Redwood L-23 2000

Perryride L-15 1500

Downtown L-14 1500

Mianus L-13 500

Roundhill L-11 900

Perryride L-16 1300

Input:

1. σ BRANCH_NAME="perryride" (LOAN)

Output:

BRANCH_NAME LOAN_NO AMOUNT

Perryride L-15 1500

Perryride L-16 1300

Project Operation:

○ This operation shows the list of those attributes that we wish to appear in the
result. Rest of the attributes are eliminated from the table.

○ It is denoted by ∏.
 Notation: ∏ A1, A2, An (r)

Where

A1, A2, A3 is used as an attribute name of relation r.

Example: CUSTOMER RELATION

NAME STREET CITY

Jones Main Harrison

Smith North Rye

Hays Main Harrison

Curry North Rye

Johnson Alma Brooklyn

Brooks Senator Brooklyn

Input:

1. ∏ NAME, CITY (CUSTOMER)

Output:

NAME CITY

Jones Harrison
Smith Rye

Hays Harrison

Curry Rye

Johnson Brooklyn

Brooks Brooklyn
 Entity Relationship Model;

ER model stands for an Entity-Relationship model. It is a high-level data model. The Entity
Relational Model is a model for identifying entities to be represented in the database and
representation of how those entities are related.
The Entity Relationship Diagram explains the relationship among the entities present in the
database
Why Use ER Diagrams In DBMS?
ER diagrams are used to represent the E-R model in a database, which makes them easy to
be converted into relations (tables).

It gives a standard solution for visualising the data logically.

For example, Suppose we design a school database. In this database, the student will be an
entity with attributes like address, name, id, age, etc.
The address can be another entity with attributes like city, street name, pin code, etc and
there will be a relationship between them.
 Graphical Notations to develop ER Diagram:

Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a
Database System.

Entity:
An Entity may be an object with a physical existence – a particular person, car, house, or
employee.
In the ER diagram, an entity can be represented as rectangles.
Entity Set:
An Entity is an object of Entity Type and a set of all entities is called as an entity set.
e.g.; E1 is an entity having Entity Type Student and set of all students is called Entity
Set.

Attribute(s):

Attributes are the properties that define the entity type. For example, Roll_No,
Name, DOB, Age, Address, Mobile_No are the attributes that define entity type (E1,
E2, E3) Student. In ER diagram, the attribute is represented by an oval.

1. Key Attribute:
The attribute which uniquely identifies each entity in the entity set is called key
attribute. For example, Roll_No will be unique for each student. In ER diagram, key
attribute is represented by an oval with underlying lines.

2. Composite Attribute:
An attribute composed of many other attribute is called as composite attribute. For
example, Address attribute of student Entity type consists of Street, City, State, and Country.
In ER diagram, composite attribute is represented by an oval comprising of ovals.

3. Multivalued Attribute:
An attribute consisting more than one value for a given entity. For example,
Phone_No (can be more than one for a given student). In ER diagram, a
multivalued attribute is represented by a double oval.
4. Derived Attribute –
An attribute that can be derived from other attributes of the entity type is
known as a derived attribute. e.g.; Age (can be derived from DOB). In ER
diagram, the derived attribute is represented by a dashed oval.

The complete entity type Student with its attributes can be represented as:

Relationship Type and Relationship Set:

Relationship Type:

A relationship type represents the association between entity types. For example,
‘Enrolled in’ is a relationship type that exists between entity type Student and Course. In ER
diagram, the relationship type is represented by a diamond and connecting the entities
with lines.

Relationship Set:
A set of relationships of the same type is known as a relationship set. The following
relationship set depicts S1 as enrolled in C2, S2 is enrolled in C1, and S3 is enrolled in C3.
Degree of a relationship set:

1. Unary Relationship –
When there is only ONE entity set participating in a
relation, the relationship is called a unary relationship.
For example, one person is married to only one person.

2. Binary Relationship –
When there are TWO entities set participating in a relationship, the relationship is
called a binary relationship. For example, a Student is enrolled in a Course.

3. n-ary Relationship –
When there are n entities set participating in a relation, the relationship is called an an
n-ary relationship.
Constraints
Constraints are used for modeling limitations on the relations between entities.
Various types of constraints on the Entity Relationship (ER) model −

● Mapping cardinality or cardinality ratio.

● Key Constraints
● Participation constraints

Mapping Cardinality
It is expressed as the number of entities to which another entity can be associated via a
relationship set.
For binary relationship set there are entity set A and B then the mapping cardinality can be
one of the following −
● One-to-one
● One-to-many
● Many-to-one
● Many-to-many

—>One-to-one relationship
One entity of A is associated with one entity of B.

We express cardinality constraints by drawing either a directed line (→), signifying

“one,” or an undirected line (—), signifying “many,” between the relationship set and
the entity set.

One-to-one relationship between an instructor and a student :

• A student is associated with at most one instructor via the relationship advisor
• A student is associated with at most one department via stud_dept
—-->One-to-many relationship
An entity set A is associated with any number of entities in B with a possibility of zero and
entity in B is associated with at most one entity in A

one-to-many relationship between an instructor and a student

• an instructor is associated with several (including 0) students via advisor
• a student is associated with at most one instructor via advisor,

—->Many-to-one relationship
An entity set A is associated with at most one entity in B and an entity set in B can be
associated with any number of entities in A with a possibility of zero.

In a many-to-one relationship between an instructor and a student,

• an instructor is associated with at most one student via advisor,
• and a student is associated with several (including 0) instructors via advisor

Many-to-many relationship
Many entities of A are associated with many entities of B.
An entity in A is associated with many entities of B and an entity in B is associated with
many entities of A.

An instructor is associated with several (possibly 0) students via advisor

▪ A student is associated with several (possibly 0) instructors via advisor
Types of keys:(Key Constraints)
1. Primary key

● It is a key which uniquely identifies a Tuple.

● In the EMPLOYEE table, ID can be the

primary key since it is unique for each
employee. In the EMPLOYEE table, we can
even select License_Number and
Passport_Number as primary keys since
they are also unique.

2. Candidate key

● A candidate key is an attribute or set of

attributes that can uniquely identify a
tuple.
● Except for the primary key, the remaining
attributes are considered a candidate key.
The candidate keys are as strong as the
primary key.

For example: In the EMPLOYEE table, id is best

suited for the primary key. The rest of the
attributes, like SSN, Passport_Number,
License_Number, etc., are considered a candidate
key.

3. Super Key

Super key is an attribute set that can uniquely

identify a tuple. A super key is a superset of a
candidate key.

For example: In the above EMPLOYEE table,

for(EMPLOEE_ID, EMPLOYEE_NAME), the name
of two employees can be the same, but their
EMPLYEE_ID can't be the same. Hence, this combination can also be a key.The super key
would be EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME), etc.
4. Foreign key

● Foreign keys are the column of the table used to point to the primary key of another
table.
● Every employee works in a specific department in a company, and employee and
department are two different entities. So
we can't store the department's
information in the employee table. That's
why we link these two tables through the
primary key of one table.
● We add the primary key of the
DEPARTMENT table, Department_Id, as a
new attribute in the EMPLOYEE table.
● In the EMPLOYEE table, Department_Id is
the foreign key, and both the tables are
related.

5. Composite key

Whenever a primary key

consists of more than one
attribute, it is known as a
composite key. This key is also
known as Concatenated Key.

For example, in employee

relations, we assume that an
employee may be assigned multiple roles, and an employee may work on multiple projects
simultaneously. So the primary key will be composed of all three attributes, namely
Emp_ID, Emp_role, and Proj_ID in combination. So these attributes act as a composite key
since the primary key comprises more than one attribute.

Entity Relationship Participation in Database (Participation constraints)

In a Relationship, Participation constraint specifies the existence of an entity when it is

related to another entity in a relationship type. It is also called minimum cardinality
constraint.

There are two types of Participation constraint −

Total Participation
Each entity in the entity set is involved in at least one relationship in a relationship set i.e.
the number of relationship in every entity is involved is greater than 0.

Consider two entities Employee and Department related via Works_For relationship. Now,
every Employee works in at least one department therefore an Employee entity exist if it
has at least one Works_For relationship with Department entity. Thus the participation of
Employee in Works_For is total relationship.Total Participation is represented by double
line in ER diagram.

Partial Participation
Each entity in entity set may or may not occur in at least one relationship in a relationship
set.

For example: Consider two entities Employee and Department and they are related to each
other via Manages relationship. An Employee must manage a Department, he or she could
be the head of the department. But not every Employee in the company manages the
department. So, participation of employee in the Manages relationship type is partial i.e.
only a particular set of Employees will manage the Department but not all.

Extended features of ER model OR Additional Features of ER Diagram

Subclasses, Superclasses, and Inheritance:

Enhanced Entity Relationship Model contains all the features of the Entity Relationship
model. In addition to all that, it also contains features of Subclasses, Superclasses and
Inheritance.
Subclasses
A subclass is a class derived from the superclass. It inherits the properties of the superclass
and also contains attributes of its own.

Car, Truck and Motorcycle are all subclasses of the superclass Vehicle. They all inherit
common attributes from vehicle such as speed, colour etc. while they have different
attributes also i.e Number of wheels in Car is 4 while in Motorcycle is 2.

Superclasses
A superclass is the class from which many subclasses can be created. The subclasses inherit
the characteristics of a superclass. The superclass is also known as the parent class or base
class.

Inheritance
Inheritance is basically the process of basing a class on another class i.e to build a class on a
existing class. The new class contains all the features and functionalities of the old class in
addition to its own.

Additional Features of ER Diagram

Generalization and Specialization

Generalization and specialization are the Enhanced Entity Relationship diagram
(EER-diagram)
1. Generalization :
It works on the principle of bottom up approach. In Generalization lower level functions are
combined to form higher level function which is called as entities. This process is repeated
further to make advanced level entities.
In the Generalization process properties are drawn from particular entities and thus we can
create generalized entity. We can summarize the Generalization process as it combines
subclasses to form superclass.
Example of Generalization –
Consider two entities Student and Patient. These two entities will have some characteristics
of their own. For example Student entity will have Roll_No, Name and Mob_No while patient
will have PId, Name and Mob_No characteristics. Now in this example Name and Mob_No of
both Student and Patient can be combined as a Person to form one higher level entity and
this process is called as Generalization Process.

2. Specialization :

We can say that Specialization is opposite of Generalization. In Specialization things are

broken down into smaller things to simplify it further. We can also say that in Specialization
a particular entity gets divided into sub entities and it’s done on the basis of it’s
characteristics. Also in Specialization Inheritance takes place.

Example of Specialization –

Consider an entity Account. This will have some attributes consider them Acc_No and
Balance. Account entity may have some other attributes like Current_Acc and Savings_Acc.
Now Current_Acc may have Acc_No, Balance and Transactions while Savings_Acc may have
Acc_No, Balance and Interest_Rate henceforth we can say that specialized entities inherits
characteristics of higher level entity.
Aggregation
In aggregation, the relation between two entities is treated as a single entity. In aggregation,
relationship with its corresponding entities is aggregated into a higher level entity.
For example: Center entity offers the Course entity act as a single entity in the relationship
which is in a relationship with another entity visitor. In the real world, if a visitor visits a
coaching center then he will never enquiry about the Course only or just about the Center
instead he will ask the enquiry about both.

Weak Entity Sets:

The entity sets which do not have sufficient attributes to form a primary key are known
as weak entity sets and the entity sets which have a primary key are known as strong
entity sets.

As the weak entities do not have any primary key, they cannot be identified on their own, so
they depend on some other entity (known as owner entity). The weak entities have
total participation constraint (existence dependency) n its identifying relationship with
owner identity. Weak entity types have partial keys. Partial Keys are set of attributes with
the help of which the tuples of the weak entities can be distinguished and identified.
Example:

In the below ER Diagram, ‘Payment’ is the weak entity. ‘Loan Payment’ is the identifying
relationship and ‘Payment Number’ is the partial key. Primary Key of the Loan along with
the partial key would be used to identify the records.
Hospital Management System