Entity-Relationship

Model

Module II - DBMS
Knowledge is not free…
You have to pay
attention!
● Conceptual Data Models for Database Design
● Entity Relationship Models
● Concept of Entity, Entity Sets, Relationship Sets, Attributes,
Domains, Constraints, Keys, Strong and Weak Entities
● Concepts of EER
● Relational Data Model - Relations, Domains and Attributes,
Tuples, Keys.
● Integrity Rules
● Relational Algebra and Operations
● Relational Calculus and Domain Calculus
● Relational Database Design using ER to Relational Mapping
 Conceptual Data Models for Database Design
★ A Data Model in Database Management System (DBMS) is the concept of
tools that are developed to summarize the description of the database.
★ Data Models provide us with a transparent picture of data which helps us in
creating an actual database.
★ It shows us from the design of the data to its proper implementation of
data.
★ It is basically classified into 3 types:-
 Conceptual Data Models for Database Design
★ The conceptual data model describes the database at a very high level and
is useful to understand the needs or requirements of the database.
★ It is this model, that is used in the requirement-gathering process i.e. before
the Database Designers start making a particular database.
○ Entity-Relationship Model( ER Model): It is a high-level data model
which is used to define the data and the relationships between them. It
is basically a conceptual design of any database which is easy to design
the view of data.
■ Design is independent of all physical considerations
■ Questions that are addressed during conceptual design:
– What are the entities and relationships of interest (miniworld)?
– What information about entities and relationships among entities
needs to be stored in the database?
– What are the constraints (or business rules) that (must) hold for
the entities and relationships?
 Entity Relationship Model
★ The Entity Relationship Model is a model for identifying entities to be
represented in the database and representation of how those entities are
related.
★ The ER data model specifies enterprise schema that represents the overall
logical structure of a database graphically.- ER Diagram
★ The Entity Relationship Diagram explains the relationship among the
entities present in the database.
★ ER models are used to model real-world objects like a person, a car, or a
company and the relation between these real-world objects.
★ The ER Diagram is the structural format of the database.
★ ER Model consists of Entities, Attributes, and Relationships among Entities
in a Database System.
Entity Relationship Model
 Entity, Entity Type and Entity Sets
★ Entity: real-world object or thing with an independent existence and which is
distinguishable from other objects.
○ Examples are a person, car, customer, product, gene, book etc.
○ An Entity may be an object with a physical existence – a particular
person, car, house, or employee – or it may be an object with a conceptual
existence – a company, a job, or a university course.
★ Entity Type: Collection of entities that all have the same attributes.
○ e.g., persons, cars, customers etc.
★ Entity Set: Collection of entities of a particular entity type
at any point in time; entity set is typically referred to using
the same name as entity type.
○ For Example, E1 is an entity having Entity Type Student
and the set of all students is called Entity Set.
○ In ER diagram, Entity Type is represented as:
 Types of Entity
There are two types of entity:

1. Strong Entity : A Strong Entity is a type of entity that has a key Attribute.
Strong Entity does not depend on other Entity in the Schema. It has a primary
key, that helps in identifying it uniquely, and it is represented by a rectangle.
These are called Strong Entity Types.

2. Weak Entity : An Entity type has a key attribute that uniquely identifies each
entity in the entity set. But some entity type exists for which key attributes can’t
be defined. These are called Weak Entity types .

For Example, A company may store the information of dependents (Parents,

Children, Spouse) of an Employee. But the dependents can’t exist without the
employee. So Dependent will be a Weak Entity Type and Employee will be
Identifying Entity type for Dependent, which means it is Strong Entity Type .
 Types of Entity- ER Diagram Representation

A weak entity type is represented by a Double Rectangle. The participation of

weak entity types is always total. The relationship between the weak entity
type and its identifying strong entity type is called identifying relationship and it
is represented by a double diamond.
 Attributes and Domain
★ Attributes are the properties that define the entity type.
★ An entity is represented by a set of attributes (its descriptive properties),
★ Attribute values that describe each entity become a major part of the data
eventually stored in a database.
★ For example, Roll_No, Name, DOB, Age, Address, and Mobile_No are the
attributes that define entity type Student.
★ Domain: A set of permitted values for an attribute. Possible domains are
integer, string, date, etc.
★ In ER diagram, the attribute is represented by an oval.
★ Types of Attributes
○ Key Attribute
○ Composite Attribute
○ Multivalued Attribute
○ Derived Attribute
 Attribute Types
1. Key Attribute: The attribute which uniquely identifies
each entity in the entity set is called the key attribute.
For example, Roll_No will be unique for each student. In
ER diagram, the key attribute is represented by an oval
with underlying lines.
2. Composite Attribute: An attribute composed of many
other attributes is called a composite attribute. For
example, the Address attribute of the student Entity
type consists of Street, City, State, and Country.
In ER diagram, the composite
attribute is represented by an
oval comprising of ovals.
 Attribute Types
3. Multivalued Attribute: An attribute consisting of 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.
 Relationship
★ 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 as enrolled
in C1, and S3 as registered in C3.
 Degree of a Relationship Set
★ The number of different entity sets participating in 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.
 Degree of a Relationship Set
3. Ternary Relationship: When there are three entity sets participating in a
relationship, the relationship is called a ternary relationship.
4. N-ary Relationship: When there are n entities set participating in a
relationship, the relationship is called an n-ary relationship.
★ Degree of a Relationship: Refers to the number of entity types that
participate in the relationship type (binary, ternary, . . . ).
★ Cardinality: The number of times an entity of an entity set participates in a
relationship set is known as cardinality .
★ Cardinality can be of different types: (Cardinality Ratio)
○ One-to-One
○ One-to-Many
○ Many-to-One
○ Many-to-Many
 Cardinality Ratio
1. One- to - One: When each entity in each entity set can take part only once
in the relationship, the cardinality is one-to-one. Let us assume that a male
can marry one female and a female can marry one male. So the relationship
will be one-to-one. The total number of tables that can be used in this is 2.

Using Sets, it can be represented as:

 Cardinality Ratio
2. One-to-Many: In one-to-many mapping as well where each entity can be
related to more than one entity and the total number of tables that can be
used in this is 2. Let us assume that one surgeon department can
accommodate many doctors. So the Cardinality will be 1 to M. It means one
department has many Doctors. Total number of tables that can used is 3.

Using sets, one-to-many cardinality can be

represented as:
 Cardinality Ratio
3. Many-to-One: When entities in one entity set can take part only once in the
relationship set and entities in other entity sets can take part more than
once in the relationship set, cardinality is many to one. Let us assume that a
student can take only one course but one course can be taken by many
students. So the cardinality will be n to 1. It means that for one course there
can be n students but for one student, there will be only one course. The
total number of tables that can be used in this is 3.

Using sets, many-to-one cardinality can be

represented as:
 Cardinality Ratio
4. Many-to-Many: When entities in all entity sets can take part more than
once in the relationship cardinality is many to many. Let us assume that a
student can take more than one course and one course can be taken by
many students. So the relationship will be many to many. The total number
of tables that can be used in this is 3.

Using sets, many-to-many cardinality can

be represented as:
 Cardinality Ratio
4. Many-to-Many: When entities in all entity sets can take part more than
once in the relationship cardinality is many to many. Let us assume that a
student can take more than one course and one course can be taken by
many students. So the relationship will be many to many. The total number
of tables that can be used in this is 3.

Using sets, many-to-many cardinality can

be represented as:
 Participation Constraint
Participation Constraint is applied to the entity participating in the relationship set.
1. Total Participation – Each entity in the entity set must participate in the
relationship. If each student must enroll in a course, the participation of
students will be total. Total participation is shown by a double line in the ER
diagram.
2. Partial Participation – The entity in the entity set may or may NOT participate
in the relationship. If some courses are not enrolled by any of the students, the
participation in the course will be partial.
The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set
having total participation and Course Entity set having partial participation.
 Participation Constraint
Participation Constraint is applied to the entity participating in the relationship set.
1. Total Participation – Each entity in the entity set must participate in the
relationship. If each student must enroll in a course, the participation of
students will be total. Total participation is shown by a double line in the ER
diagram.
2. Partial Participation – The entity in the entity set may or may NOT participate
in the relationship. If some courses are not enrolled by any of the students, the
participation in the course will be partial.
The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set
having total participation and Course Entity set having partial participation.
 Participation Constraint
Using Set, it can be represented as,

Every student in the Student Entity set participates in a relationship but there
exists a course C4 that is not taking part in the relationship.
 KEYS
● Keys are used to uniquely identify any record or row of data from the table.
● It is also used to establish and identify relationships between tables.
ID is used as a key in the
STUDENT table because it is
unique for each student.

In the PERSON table,

passport_number,
license_number, SSN are keys
since they are unique for each
person.
 Types of KEYS

1. Primary key: It is the first key used to identify one and only
one instance of an entity uniquely. An entity can contain
multiple keys.
The key which is most suitable from those lists becomes a
primary key.
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.
 Types of KEYS
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.
 Types of KEYS
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.
In the 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.
 Types of KEYS
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.
DEPARTMENT

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.
 Types of KEYS
5. Alternate key: There may be one or more attributes or a combination of
attributes that uniquely identify each tuple in a relation. These attributes or
combinations of the attributes are called the candidate keys.
One key is chosen as the primary key from these candidate keys, and the
remaining candidate key, if it exists, is termed the alternate key.
In other words, the total number of the alternate keys is the total number of
candidate keys minus the primary key. The alternate key may or may not exist.
If there is only one candidate key in a relation, it does not have an alternate
key.
 Types of KEYS
6. 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.
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.
 Types of KEYS
7. Artificial key: The key created using arbitrarily assigned data are known as
artificial keys. These keys are created when a primary key is large and
complex and has no relationship with many other relations. The data values
of the artificial keys are usually numbered in a serial order.
The primary key, which is composed of Emp_ID, Emp_role, and Proj_ID, is
large in employee relations. So it would be better to add a new virtual
attribute to identify each tuple in the relation uniquely.
 Key Constraints
Constraints are the rules that are to be followed while entering data into columns
of the database table.
Constraints ensure that data entered by the user into columns must be within the
criteria specified by the condition.
For example, if you want to maintain only unique IDs in the employee table or if
you want to enter only age under 18 in the student table etc.
We have 5 types of key constraints in DBMS:
★ NOT NULL: ensures that the specified column doesn’t contain a NULL value.
★ UNIQUE : provides a unique/distinct values to specified columns.
★ DEFAULT: provides a default value to a column if none is specified.
★ CHECK :checks for the predefined conditions before inserting the data inside
the table.
★ PRIMARY KEY: it uniquely identifies a row in a table.
★ FOREIGN KEY: ensures referential integrity of the relationship
 Key Constraints
1. Not Null

Null represents a record where data may be missing data or data for that
record may be optional.

Once not null is applied to a particular column, you cannot enter null values to
that column and restricted to maintain only some proper value other than null.

2. Unique

Unique constraint ensures that all values in a column are unique

Example: CREATE TABLE Persons (

ID int UNIQUE,
LastName varchar(255) NOT NULL,
FirstName varchar(255), Age int);
 Key Constraints
3. Primary Key

A primary key is a constraint in a table that uniquely identifies each row record
in a database table by enabling one or more the columns in the table as the
primary key.

Example:

CREATE TABLE CUSTOMER(

ID INT ,
NAME VARCHAR (20) ,
COURSE VARCHAR(10) ,
PRIMARY KEY (ID)
);
 Key Constraints
4. DEFAULT
Default clause in SQL is used to add default data to the columns. When a
column is specified as default with some value then all the rows will use the
same value i.e each and every time while entering the data we need not enter
that value. But default column value can be customized i.e it can be overridden
when inserting a data for that row based on the requirement.
Example: CREATE TABLE emp (
ID int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Age int,
City varchar(255) DEFAULT 'hyderabad'
);
 Key Constraints
5. Check
Check constraint ensures that the data entered by the user for that column is
within the range of values or possible values specified.
Example: CREATE TABLE STUDENT (
ID int ,
Name varchar(255) ,
Age int,
CHECK (Age>=18)
);
6. Foreign Key
The foreign key a constraint is a column or list of columns that points to the
primary key column of another table. The main purpose of the foreign key is
only those values are allowed in the present table that will match the primary
key column of another table.
 Key Constraints
Examples to create Primary Key and Foreign Key:
CREATE TABLE CUSTOMER1(
ID INT ,
NAME VARCHAR (20) ,
COURSE VARCHAR(10) ,
PRIMARY KEY (ID)
);

CREATE TABLE CUSTOMER2(

ID INT ,
MARKS INT,
REFERENCES CUSTOMER1(ID)
);
 EER - Enhanced ER Model
The ER model is the abstract representation of a database structure that defines
★ Entities in a database.
★ Attributes that they had.
★ Relationships between them.

What is an Enhanced ER model?

Enhanced ERDs are high-level models that represent the requirements and
complexities of complex databases.
The EER model includes all modeling concepts of the ER model.
EER includes:
★ Subclasses and Superclasses
★ Specialization and Generalization
★ Category or Union type
★ Attribute and relationship inheritance
 EER - Enhanced ER Model
● Superclass and Subclass
A superclass is a high-level entity that can be further segmented into subclasses
or subsets. It is also referred to as a Parent class. A subclass can be referred to as
a child or derived class.
Eg: Science is a Super class which has subclasses Physics, Chemistry, Biology.

● Generalization and Specialization

Specialized classes are often called subclass while a generalized class is called a
superclass.
A sub-class is best understood by “IS-A analysis”.
Eg: “Technician IS-A Employee”, and “Laptop IS-A Computer”.
An entity is a specialized type/class of another entity. For example, a Technician is
a special Employee in a university system Faculty is a special class of Employees.
We call this phenomenon generalization/specialization.
In the example here Employee is a generalized entity class while the Technician
and Faculty are specialized classes of Employee.
 EER - Enhanced ER Model
Constraints
There are two types of constraints on subclasses which are described below:
1. Total or Partial:
A total subclass relationship is one where the union of all the subclasses is equal
to the superclass. It means if every superclass entity has some subclass entity,
then it is called a total subclass relationship.
Let's suppose if the union of all the subclasses ( engineer, clerk, lab assistant) is
equal to the total employee. Then the relationship is total. In the above example,
it is a total relationship.
If all the entities of a superclass are not associated with a subclass, then it is
called a partial subclass relationship.
2. Overlapped or Disjoint:
If any entity from the superclass is associated with more than one subclass, then
it is known as overlapped subclassing, and if it is associated with zero or only one
subclass, then it is called disjoint subclassing.
 EER - Enhanced ER Model
Multiple Inheritance
When one subclass is associated with more than one superclass, then this
phenomenon is known as multiple inheritance. In multiple inheritance, the
attributes of the subclass will be the union of all the superclass attributes which
are associated with it.
For example, a teacher is a subclass that can be associated with the superclass of
an employee and a superclass of faculty. In the same way, a monitor in the class
can be a subclass of a student superclass as well as an alumni superclass.

UNION
Let's suppose we have a vehicle superclass, and we have two subclasses, car and
bike. These two subclasses will inherit the attributes from the vehicle superclass.
Now we have a UNION of those vehicles which are RTO registered, so we have a
UNION of cars and bikes, but they will inherit all the attributes from the vehicle
superclass.
EER - Enhanced ER Model
 Relational Data Model
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.
The relational model uses a collection of tables to represent both data and the
relationships among those data. Each table has multiple columns, and each
column has a unique name. Tables are also known as relations.
The relational model is an example of a record-based model.
Record-based models are so named because the database is structured in
fixed-format records of several types.
Each table contains records of a particular type. Each record type defines a fixed
number of fields, or attributes.
The columns of the table correspond to the attributes of the record type.
The relational model represents how data is stored in Relational Databases. A
relational database consists of a collection of tables, each of which is assigned a
unique name.
 Relational Data Model
Attribute: The properties that
define an entity. e.g.; ROLL_NO,
NAME, ADDRESS

Relation Schema: A relation

schema defines the structure of
the relation and represents the
name of the relation with its
attributes. e.g.; STUDENT
(ROLL_NO, NAME, ADDRESS,
Tuple: Each row in the relation is known as a PHONE, and AGE) is the relation
tuple. The above relation contains 4 tuples, schema for STUDENT. If a schema
one of which is shown as: has more than 1 relation, it is
1 RAM DELHI 9455123451 18 called Relational Schema.
 Relational Data Model
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.
Degree: The number of attributes in the relation is known as the degree of the
relation. The STUDENT relation defined above has degree 5.
Cardinality: The number of tuples in a relation is known as cardinality. The
STUDENT relation defined above has cardinality 4.

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

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.
 Relational Data Model
TUPLES
A tuple is a single row in a database that contains a single record for such a
relation. A row or record represent a set of connected data.

Elon Musk 236-455-1233 [email protected] PO Box 123, Seattle,

WA 98100
 Relational Data Model
Types of TUPLES
● 1-Tuple: Contains one element, like (123) in a table with one column.
● 2-Tuple: Contains two elements, like (123, 'Alice') in a table with two
columns.
● n-Tuple: A general term for tuples with 'n' elements, like (123, 'Alice', 25) for
three columns.
● Ordered Tuples: Elements have a specific order, so (123, 'Alice', 25) is
different from ('Alice', 123, 25).
● Composite Tuples: Tuples that include other tuples, like an address tuple
within a person tuple.
● Homogeneous vs. Heterogeneous Tuples: Homogeneous tuples have
elements of the same type, while heterogeneous tuples have elements of
different types.
 Relational Data Model
KEYS
● Keys help to uniquely identify records in a table, which prevents duplication
and ensures data integrity.
● Keys also establish relationships between different tables, allowing for
efficient querying and management of data.
● Without keys, it would be difficult to retrieve or update specific records, and
the database could become inconsistent or unreliable.
● Different Types of Database Keys:
○ Super Key
○ Candidate Key
○ Primary Key
○ Alternate Key
○ Foreign Key
○ Composite Key
 Relational Data Model
KEYS - Super Key
The set of one or more attributes (columns) that can uniquely identify a tuple
(record) is known as Super Key.
For Example, STUD_NO, (STUD_NO, STUD_NAME), etc.
A super key is a group of single or multiple keys that uniquely identifies rows
in a table. It supports NULL values in rows.
A super key can contain extra attributes that aren’t necessary for uniqueness.
For example, if the “STUD_NO” column can uniquely identify a student, adding
“SNAME” to it will still form a valid super key, though it’s unnecessary.
Example:Table STUDENT
STUD_NO SNAME ADDRESS PHONE
1 Shyam Delhi 123456789
2 Rakesh Kolkata 223365796
3 Suraj Delhi 175468965
STUD_NO+PHONE is a super key.
 Relational Data Model
KEYS - Candidate Key
The minimal set of attributes that can uniquely identify a tuple is known as a candidate
key. For Example, STUD_NO in STUDENT relation.
● A candidate key is a minimal super key, meaning it can uniquely identify a record
but contains no extra attributes.
● It is a super key with no repeated data is called a candidate key.
● The minimal set of attributes that can uniquely identify a record.
● A candidate key must contain unique values, ensuring that no two rows have the
same value in the candidate key’s columns.
● Every table must have at least a single candidate key.
● A table can have multiple candidate keys but only one primary key.
Example: STUD_NO is the candidate key for relation STUDENT.
STUD_NO SNAME ADDRESS PHONE
1 Shyam Delhi 123456789
2 Rakesh Kolkata 223365796
3 Suraj Delhi 175468965
 Relational Data Model
KEYS - Candidate Key

Example: {STUD_NO, COURSE_NO} is a composite candidate key for relation

STUDENT_COURSE.
Table STUDENT_COURSE
STUD_NO TEACHER_NO COURSE_NO
1 001 C001
2 056 C005

● The candidate key can be simple (having only one attribute) or composite as well.
● A unique constraint that has a nullable column, allows the value ‘ null ‘ in that
column only once . That’s why the STUD_PHONE attribute is a candidate here, but
can not be a ‘null’ value in the primary key attribute.
 Relational Data Model
KEYS - Primary Key
There can be more than one candidate key in relation out of which one can be
chosen as the primary key.
For Example, STUD_NO, as well as STUD_PHONE, are candidate keys for relation
STUDENT but STUD_NO can be chosen as the primary key.
(only one out of many candidate keys)
A primary key is a unique key, meaning it can uniquely identify each record (tuple)
in a table.
It must have unique values and cannot contain any duplicate values.
A primary key cannot be NULL, as it needs to provide a valid, unique identifier for
every record.
A primary key does not have to consist of a single column. In some cases, a
composite primary key (made of multiple columns) can be used to uniquely
identify records in a table.
Databases typically store rows ordered in memory according to primary key for
fast access of records using primary key.
 Relational Data Model
KEYS - Primary Key

Example:

STUDENT table -> Student(STUD_NO, SNAME, ADDRESS, PHONE)

STUD_NO is a primary key

Table STUDENT

STUD_NO SNAME ADDRESS PHONE

1 Shyam Delhi 123456789
2 Rakesh Kolkata 223365796
3 Suraj Delhi 175468965
 Relational Data Model
KEYS - Alternate Key

An alternate key is any candidate key in a table that is not chosen as the primary
key. In other words, all the keys that are not selected as the primary key are
considered alternate keys.
An alternate key is also referred to as a secondary key because it can uniquely
identify records in a table, just like the primary key.
An alternate key can consist of one or more columns (fields) that can uniquely
identify a record, but it is not the primary key
Eg:- SNAME, and ADDRESS is Alternate keys
Example: STUD_NO, as well as PHONE both,
are candidate keys for relation STUDENT
but PHONE will be an alternate key (only one
out of many candidate keys).
 Relational Data Model
KEYS - Foreign Key
A foreign key is an attribute in one table that refers to the primary key in another
table. The table that contains the foreign key is called the referencing table, and
the table that is referenced is called the referenced table.
A foreign key in one table points to the primary key in another table,
establishing a relationship between them. It helps connect two or more tables,
enabling to create relationships
between them.

This is essential for maintaining

data integrity and preventing
data redundancy.

They act as a cross-reference

between the tables.
 Relational Data Model
KEYS - Composite Key
To uniquely identify rows of a table, a combination of two or more
columns/attributes can be used. It still can give duplicate values in rare cases. So,
we need to find the optimal set of attributes that can uniquely identify rows in a
table. It acts as a primary key if there is no primary key in a table
Two or more attributes are used together to make a composite key .
Different combinations of attributes
may give different accuracy in terms
of identifying the rows uniquely.
Example: FULLNAME + DOB can be
combined together to access the
details of a student.
 INTEGRITY RULES
● The set of principles, also known as the integrity rules or constraints
● helps to manage the data stored in the system in the right way
● determine whether it’s suitable for certain purposes
● Integrity rules represent the pre-existing conditions, or constraints, of data
stored in the database that will ensure the data is valid and consistent.
● These rules, defining permissible values, relationships, and data
operations enclosed in the database system, ensure the accuracy and
reliability of the data to be used for its purposes.
● Rules for integrity are considered barriers towards the possibility of some
operations over the database, such as deletion, modification, or insertion
of data whose accuracy is doubtful or inconsistent, thus enabling the
database to be of high quality.
 INTEGRITY RULES
Types of Integrity Rules:
● Entity Integrity: A primary key will be ensured of non-duplication, which also
implies that no null values are allowed in the primary key column, thus uniquely
identifying each instance of an entity in the table.
● Referential Integrity: For every foreign key value in a child table, that value has to
possess the same primary key value in the parent table. This is the only way to
maintain foreign keys and make father child relationships work properly.
● Domain Integrity: Verifying domain validity means finding out if the value lies
within the allowed range for a particular attribute column in the data table. It
implements data integrity by specifying data formats, ranges, and constraints, for
example, check constraints and limitations, that ensure that all officially recognized
data are kept.
● User-defined Integrity: This is an enterprise-specific set of integrity rules that
would be established by different organizations depending on their business edges
and the rules ascribed to sensitive data.
 INTEGRITY RULES
Significance of Integrity Rules:
➔ Data Quality: Integrity rules make sure data is precisely moderated,
elaborated, and of high- quality in the database, just like the data quality and
reliability.
➔ Data Security: Integrity rules classify together while limiting and validating
requests. They are effective in defending against unauthorized access, data
breaches, and data manipulation attacks.
➔ Data Consistency: Ethical parameters help create a homogeneous database,
preventing data inconsistencies, anomalies, and errors that could arise from
invalid and incorrect data keystrokes, hence allowing for data stemming from
valid data sources that are consistently coherent and reliable both qualitatively
and quantitatively.
 Relational Algebra and Operations
Relational algebra consists of a certain set of rules or operations that are widely
used to manipulate and query data from a relational database.
It can be facilitated by utilizing SQL language and helps users interact with
database tables based on querying data from the database more efficiently and
effectively.
Relational Algebra incorporates a collection of operations, such as filtering data or
combining data, that help us organize and manipulate data more efficiently.
This ” algebra ” is the foundation for most database queries, and it enables us to
extract the required information from the databases by using SQL query language.
Relational algebra consists of various operators that help us fetch and manipulate
data from relational tables in the database to perform certain operations on
relational data.
 Relational Algebra and Operations
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)
 Relational Algebra and Operations
1. Selection(σ) : used to filter out rows from a given table based on certain given
condition. It basically allows you to retrieve only those rows that match the
condition as per condition passed during SQL Query.
It is used to select required tuples of the relations.
If we want to get the details of all the employees in the Department “IT”, we would
use the selection operator to filter out these based on the given condition.
σ(department=’IT’)EMPLOYEE

Example: R Output Table : For the above relation, σ(c>3)R will select the
A B C tuples which have c more than 3.
1 2 4 A B C
2 2 3 1 2 4
3 2 3 4 3 4
4 3 4
 Relational Algebra and Operations
2. Projection(π) : While Selection operation works on rows , similarly projection
operation of relational algebra works on columns.
It basically allows you to pick specific columns from a given relational table based
on the given condition and ignoring all the other remaining columns.
If we are interested in the specific columns from the relational tables, we would
prefer to use the Projection Operator.
It is used to project required column data from a relation.
Example: Suppose we want columns B and C from Relation R.
π(B,C)R will show following columns.
B C
2 4
2 3
3 4 [By Default, projection removes duplicate data.]
 Relational Algebra and Operations
3. Union(U) : Used to combine the results of two queries into a single result. The
only condition is that both queries must return same number of columns with same
data types.
If in case we want a list of all the employee from two different department . Then in
that case we should use union operation to merge both the list from two different
department. Union operation in relational algebra is the same as union operation in
set theory.
Example: FRENCH GERMAN
Student_Name Roll_Number Student_Name Roll_Number
Ram 01 Vivek 13
Mohan 02 Geeta 17
Vivek 13 Shyam 21
Geeta 17 Rohan 25
 Relational Algebra and Operations
Consider the following table of Students having different optional subjects in their
course.
π(Student_Name)FRENCH U π(Student_Name)GERMAN

Student_Name
Ram
Mohan
Vivek
Geeta
Shyam
Rohan
The only constraint in the union of two relations is that both relations must have the
same set of Attributes.
 Relational Algebra and Operations
Consider the following table of Students having different optional subjects in their
course.
π(Student_Name)FRENCH U π(Student_Name)GERMAN

Student_Name
Ram
Mohan
Vivek
Geeta
Shyam
Rohan
The only constraint in the union of two relations is that both relations must have the
same set of Attributes.
 Relational Algebra and Operations
4. Set Difference(-) : Set difference basically provides the rows that are present in
one table , but not in another tables.
Example: From the above table of FRENCH and GERMAN, Set Difference is used
as follows: π(Student_Name)FRENCH - π(Student_Name)GERMAN
Student_Name
Ram
Mohan
The only constraint in the Set Difference between two relations is that both
relations must have the same set of Attributes.
π(Student_Name) GERMAN- π(Student_Name)FRENCH
Student_Name
Shyam
Rohan
 Relational Algebra and Operations
5. Set Intersection(∩) : Set Intersection basically allows to fetches only those rows
of data that are common between two sets of relational tables.
Example: From the above table of FRENCH and GERMAN, the Set Intersection is
used as follows: π(Student_Name)FRENCH ∩ π(Student_Name)GERMAN
Student_Name
Vivek
Geeta The only constraint in the Set Difference between two relations
is that both relations must have the same set of Attributes.
6. Rename(ρ) : allows you to give a temporary name to a specific relational table
or to its columns. It is very useful when we want to avoid ambiguity, especially in
complex Queries. Rename is a unary operation used for renaming attributes of a
relation. ρ(a/b)R will rename the attribute 'b' of the relation by 'a'.
 Relational Algebra and Operations
7. Cross Product(X) : Cartesian product Operator combines every row of one
table with every row of another table , producing all the possible combination. It’s
mostly used as a precursor to more complex operation like joins.
Cross-product between two relations. Let’s say A and B, so the cross product
between A X B will result in all the attributes of A followed by each attribute of B.
Each record of A will pair with every record of B.

Example: A B
Name Age Sex ID Course
Ram 14 M 1 DS
Sona 15 F 2 DBMS
Kim 20 M
 Relational Algebra and Operations
AXB
Name Age Sex ID Course
Ram 14 M 1 DS
Ram 14 M 2 DBMS
Sona 15 F 1 DS
Sona 15 F 2 DBMS
Kim 20 M 1 DS
Kim 20 M 2 DBMS
If A has ‘n’ tuples and B has ‘m’ tuples then A X B will have ‘ n*m ‘ tuples.
 Relational Algebra and Operations
Derived Operators: These are some of the derived operators, which are derived
from the fundamental operators.
1. Natural Join(⋈): Natural join is a binary operator. Natural join between two or
more relations will result in a set of all combinations of tuples where they have an
equal common attribute. Example:
EMP DEPT
Name ID Dept_Name Dept_Name Manager
A 120 IT Sales Y
B 125 HR Production Z
C 110 Sales IT A
D 111 IT
Natural join between EMP and DEPT with condition :
EMP.Dept_Name = DEPT.Dept_Name
 Relational Algebra and Operations
EMP ⋈ DEPT
Name ID Dept_Name Manager
A 120 IT A
C 110 Sales Y
D 111 IT A
2. Conditional Join: Conditional join works similarly to natural join. In natural join,
by default condition is equal between common attributes while in conditional join
we can specify any condition such as greater than, less than, or not equal.
Example: R S
ID Sex Marks ID Sex Marks
1 F 45 10 M 20
2 F 55 11 M 22
3 F 60 12 M 59
 Relational Algebra and Operations
Join between R and S with condition R.marks >= S.marks

R.ID R.Sex R.Marks S.ID S.Sex S.Marks

1 F 45 10 M 20
1 F 45 11 M 22
2 F 55 10 M 20
2 F 55 11 M 22
3 F 60 10 M 20
3 F 60 11 M 22
3 F 60 12 M 59
 Relational Algebra and Operations
Relational algebra in database management systems solved exercise
TRY THE ABOVE PROBLEM
 Relational Calculus and Domain Calculus
● Relational calculus is a non-procedural query language.
● In the non-procedural query language, the user is concerned with the details
of how to obtain the end results. The relational calculus tells what to do but
never explains how to do.
● It is based on Predicate calculus, a name derived from branch of symbolic
language. A predicate is a truth-valued function with arguments. On
substituting values for the arguments, the function result in an expression
called a proposition. It can be either true or false.
● Many of the calculus expressions involves the use of Quantifiers. There are
two types of quantifiers:
○ Universal Quantifiers
○ Existential Quantifiers
 Relational Calculus and Domain Calculus
● Universal Quantifiers: The universal quantifier denoted by ∀ is read as for all
which means that in a given set of tuples exactly all tuples satisfy a given
condition.
● Existential Quantifiers: The existential quantifier denoted by ∃ is read as for
all which means that in a given set of tuples there is at least one occurrences
whose value satisfy a given condition.
● Types of Relational calculus:
 Relational Calculus and Domain Calculus
1. Tuple Relational Calculus (TRC)
● a non-procedural query language which is based on finding a number of tuple
variables also known as range variable for which predicate holds true.
● It describes the desired information without giving a specific procedure for
obtaining that information.
● The tuple relational calculus is specified to select the tuples in a relation.
● In TRC, filtering variable uses the tuples of a relation. The result of the
relation can have one or more tuples.
Notation: A Query in the tuple relational calculus is expressed as following
notation
{T | P (T)} or {T | Condition (T)}

Where T is the resulting tuples, P(T) is the condition used to fetch T.

 Relational Calculus and Domain Calculus
1. Tuple Relational Calculus (TRC)
For example:
{ T.name | Author(T) AND T.article = 'database' }
Output: This query selects the tuples from the AUTHOR relation. It returns a tuple
with 'name' from Author who has written an article on 'database'.

TRC (tuple relation calculus) can be quantified.

In TRC, we can use Existential (∃) and Universal Quantifiers (∀).
For example:
{ R| ∃T ∈ Authors(T.article='database' AND R.name=T.name)}
Output: This query will yield the same result as the previous one.
 Relational Calculus and Domain Calculus
2. Domain Relational Calculus (DRC)
● In domain relational calculus, filtering variable uses the domain of attributes.
● Domain relational calculus uses the same operators as tuple calculus.
● It uses logical connectives ∧ (and), ∨ (or) and ┓ (not).
● It uses Existential (∃) and Universal Quantifiers (∀) to bind the variable.
● The QBE or Query by example is a query language related to domain
relational calculus.
Notation: { a1, a2, a3, ..., an | P (a1, a2, a3, ... ,an)}
Where, a1, a2 are attributes and P stands for formula built by inner attributes

For example: {< article, page, subject > | ∈ magazine ∧ subject = 'database'}
Output: This query will yield the article, page, and subject from the relational
magazine, where the subject is a database.
Relational Database Design using ER to Relational Mapping

ER-Diagram for a
Company Database
Relational Database Design using ER to Relational Mapping
Now, let’s dive in to convert this ER-Diagram to Relational Schema…
Step 1: Figure out all the regular/strong entity from the diagram and then
create a corresponding relation that includes all the simple attributes.
● Choose one of the attributes as a primary key. If composite, the
simple attributes together form the primary key.
● For the given ER-Diagram we have Employee, Department and
Project as strong/regular
entity, as they are enclosed
in single rectangle.
● So, we create respective
relations that is depicted in
the figure.
Relational Database Design using ER to Relational Mapping
Step 2: Figure out the weak entity types from the diagram and create
a corresponding relation that includes all its simple attributes.
● Add as foreign key all of the primary key attributes in the entity
corresponding to the owner entity.
● The primary key is a combination of all the primary key attributes
from the owner and the
primary key of the weak
entity.
● For the ER-Diagram we
have Dependent as a
weak entity, as it is
enclosed in a double
rectangle that is indicative
of an entity being weak.
Relational Database Design using ER to Relational Mapping
Step 3: Now we need to figure out the entities from ER diagram for
which there exists a 1-to-1 relationship.
● The entities for which there exists a 1-to-1 relationship, choose one
relation as S, the other as T.
● Better if S has total participation.
● Then we need to add to S all the simple attributes of the relationship
if there exists any.
● After that, we add as a foreign key in S the primary key attributes of
T.
● For the given ER-Diagram there exists a 1-to-1 relationship between
Employee and Department entity.
● Here Department has total participation therefore consider it as
relation S and Employee as relation T.
Relational Database Design using ER to Relational Mapping
Step 3:
The 1-to-1 mapping between Employee and Department is depicted
in the figure below.
Relational Database Design using ER to Relational Mapping
Step 4:
Now we need to figure out the entities from ER diagram for which
there exists a 1-to-N relationship.
● The entities for which there exists a 1-to-N relationship, choose a
relation as S as the type at N-side of relationship and other as T.
● Then we add as a foreign key to S all of the primary key attributes of
T.
● In the given ER diagram there are two 1-to-N relationships that
exists between Employee-Department and Employee-Dependent
entity.
● The 1-to-N mapping between Employee-Department and
Employee-Dependent is depicted in the figure below.
Relational Database Design using ER to Relational Mapping
Step 4:
Relational Database Design using ER to Relational Mapping
Step 5:
Now we need to figure out the entities from ER diagram for which
there exists an M-to-N relationship.
● Create a new relation S.
● The primary keys of relations between which M-to-N relationship
exists, are added to the new relation S created, that acts as a
foreign key.
● Then we,add any simple attributes of the M-to-N relationship to S.
● For the given ER-Diagram there exists M-to-N relationship between
Employee and Project entity.
● The new table Works_On is created for mapping the relationship
between Employee and Project relation.
Relational Database Design using ER to Relational Mapping
Step 5:
Relational Database Design using ER to Relational Mapping
Step 6:
Now identify the relations that contain multi-valued attributes.
● Then we need to create a new relation S
● In the new relation S we add as foreign keys the primary keys of the
corresponding relation.
● Then we add the multi-valued attribute to S; the combination of all
attributes in S forms the primary key.
● For the given ER-Diagram there exists a multi-valued attribute
(Locations) in Department relation.
● So, we create a new relation called Dept_Locations. To this new
relation we add the primary key of Department Table that is
D_Number and the multi-valued attribute Locations.
Relational Database Design using ER to Relational Mapping
Step 6:

We have successfully mapped

the ER-Diagram of the
Company Database to its
Relational Schema.
Follow these 6 steps to
successfully map any
ER-Diagram to its Relational
Schema.
Relational Database Design using ER to Relational Mapping

Find more examples:

https://nulab.com/learn/software-development/er
-diagrams-vs-eer-diagrams-whats-the-difference/
 Revision questions
2 Mark Questions:
1. What are different Relationship sets? Explain.
2. Define i)Super key ii)Candidate key
3. What are domain constraints?
4. Differentiate between primary key and foreign key with examples.
5. Discuss the concept of ‘Entity’.
6. Define relationship amd relationship sets.
7. What is meant by weak entity?
8. Define cardinality.
9. Explain selection and projection operation with example.
10. What do you mean by instances and schemas?
11. Define tuple and give example.
 5 Mark Questions: Revision questions
1. List various set operation and explain them.(Relational algebra operations)
2. Different types of integrity constraints.
3. Discuss different extended ER features.
4. What is domain calculus? Explain with example.
5. Draw the ER diagram for a company needs to store information about
employees (identified by CEN, with salary and phone as attributes),
departments (identified by Dno, with Dname and budget as attributes), and
children of employees (with Cname and Cage as attributes). Employees
work in departments, each department is managed by an employee, a child
must be identified uniquely by name when the parent (who is an employee;
assume that only one parent works for the company) is known. We are not
interested in information about a child once the parent leaves the company
6. Write short note on relational model and entity relationship model.
7. Discuss the conceptual design with the ER-Model.
8. Differentiate weak and strong entities.
9. What are the different types of relationships?
10. Draw an ER diagram for simple BANK database schema.
10 Mark Questions:
Revision questions
1. What is an Attribute? Explain types of attributes used in ER how it represented
in ER diagram?
2. Explain ER diagram with example.
3. Write a short note on aggregation, generalization and specialization.
4. Explain different types of keys with example.
5. Write a comparison on relational calculus and domain calculus.
6. Draw a library database with foreign key references and their ER diagram.
7. Draw ER model for customer and order.
Explain the mapping constraints.
8. Convert the following ER diagram to into
relational model:
 Thank You
Happy Learning!