Unit 2- Relational Relational Model

• ER and EER diagrams: Components of ER model, Conventions, Converting

ER diagrams into tables Relational Model: Basic concepts, Attributes and
Domains, Codd’s rules
• Relational Integrity: Nulls, Entity, Referential integrities, Enterprise
constraints, Views, Schema diagram

1
 Unit 3- Relational Database Design

• Relational Model:
– Basic concepts,
– Attributes and Domains,
– CODD's Rules

2
 Relational model

– Relations are Two-Dimensional Tables.

– It is easy to implement and easy to simplify to manipulate the data.
– This is the most popular data model.
– It uses the primary key and secondary key to connect any two files.
– A Relational Database Model consists of relations to connect them by
key fields.
– A relation has some attributes. The relation is represented in rows and
columns.
– Each column of the relation is called an attribute.
– Each row in the relation is called a tuple.
– Each relation can have one unique column i.e. primary key.
– Each relation can have n-columns and n-tuple.

3
 Relational model

– Each relation is preceded by the name of that relation.

– The fields of the relations are separated by commas and placed within
the parentheses of the relation.
– The relational model represents data in the form of relations or tables.
Relational Model can be represented as shown below
STUDENT (StudNo, Sname, Special)
ENROLLMENT (StudNo, Subcode, marks)
SUBJECT (Subcode, Subname, Maxmarks, Faccode)
FACULTY (Faccode, Fname, Dept)

4
 Relational model - Terminologies

• Relational Schema: Schema represents the structure of a relation.

• Example: Relational Schema of STUDENT relation can be represented as
STUDENT(STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY,
STUD_AGE).
• Attribute: Each relation is defined in terms of some properties, each of which is
known as an attribute i.e. column of a table.
• Example: STUD_NO, STUD_NAME, etc. are attributes of relation STUDENT.
• Each attribute in a relation has only one data value corresponding to it i.e. they do
not contain two or more values.
• Domain of an attribute: The possible values, an attribute can take in a relation is
called its domain. Example: domain of STUD_AGE can be from 18 to 40. the domain
of gender attributes is a set of data values "M" for male and "F" for female.
• Tuple: Each row of a relation is known as a tuple.

5
 Relational model - Terminologies

• Cardinality: The total number of rows at a time in a relation is called the

cardinality of that relation. For example: In a student relation, the total number
of tuples in the relation is 3 so the cardinality of a relation is 3.
• The cardinality of a relation changes with time as more and more tuples get
added or deleted.
• Degree: The total number of attributes in a relationship. The relation with one
attribute is called unary relation, with two attributes is known a binary relation
and with three attributes is known as ternary relation.
• For example: in the Student relation, the total number of attributes is 5, so the
degree of the relations is 5. The degree of a relation does not change with time
as tuples get added or deleted.

6
 Relational model - Terminologies

Relation Table
Tuple Row, Record
Attribute Column, Field
Domain It consists of set of legal
values
Cardinality It consists of number of rows
Degree It contains number of columns

7
 Relational model - Operations

• Following are the basic operations that can be performed on a

relational model:
• Insertion Operation
• Deletion Operation
• Update Operation
• Retrieval Operation

8
 Relational model – Codd rules

• Rule 1: The Information Rule

• All information, whether it is user information or metadata, that is stored in
a database must be entered as a value in a cell of a table. It is said that
everything within the database is organized in a table layout.
• Rule 2: The Guaranteed Access Rule
• Each data element is guaranteed to be accessible logically with a
combination of the table name, primary key (row value), and attribute
name (column value).
• Rule 3: Systematic Treatment of NULL Values
• Every Null value in a database must be given a systematic and uniform
treatment.

9
 Relational model – Codd rules

• Rule 4: Active Online Catalog Rule

• The database catalog, which contains metadata about the database, must be
stored and accessed using the same relational database management
system.
• Rule 5: The Comprehensive Data Sublanguage Rule
• A crucial component of any efficient database system is its ability to offer an
easily understandable data manipulation language (DML) that facilitates
defining, querying, and modifying information within the database.
• Rule 6: The View Updating Rule
• All views that are theoretically updatable must also be updatable by the
system.

10
 Relational model – Codd rules

• Rule 7: High-level Insert, Update, and Delete

• A successful database system must possess the feature of facilitating
high-level insertions, updates, and deletions that can grant users the ability
to conduct these operations with ease through a single query.
• It also supports union, intersection and minus operation in the database
system.
• Rule 8: Physical Data Independence
• Application programs and activities should remain unaffected when
changes are made to the physical storage structures or methods.
• Rule 9: Logical Data Independence
• Application programs and activities should remain unaffected when
changes are made to the logical structure of the data, such as adding or
modifying tables.
11
 Relational model – Codd rules

• Rule 10: Integrity Independence

• Integrity constraints should be specified separately from application
programs and stored in the catalog. They should be automatically enforced
by the database system.
• Rule 11: Distribution Independence
• The distribution of data across multiple locations should be invisible to
users, and the database system should handle the distribution transparently.
• Rule 12: Non-Subversion Rule
• The non-submersion rule defines RDBMS as a SQL language to store and
manipulate the data in the database.
• If a system has a low-level or separate language other than SQL to access the
database system, it should not subvert or bypass integrity to transform data.

12
 Database Design and ER Model

• Entity, Attributes, Relationships, Constraints, types of Keys, Design

Process,
• ER Diagram,
• Design Issues,
• Extended E-R Features,
• converting E-R diagram into tables

13
Department of AIML ZCOER, Pune
 Database Design and ER Model

• An Entity Relationship Diagram (ER Diagram) pictorially explains the

relationship between entities to be stored in a database.
• An ER Diagram in DBMS plays a crucial role in designing the database.
• Today’s business world previews all the requirements demanded by
the users in the form of an ER Diagram.
• Later, it's forwarded to the database administrators to design the
database.
• It acts as a framework created with specialized symbols for the
purpose of defining the relationship between the database entities.
• ER diagram is created based on three principal components: entities,
attributes, and relationships.

14
Department of AIML ZCOER, Pune
 Database Design and ER Model

• Why Use ER Diagrams in DBMS?

• ER Diagram helps you conceptualize the database and lets you know
which fields need to be embedded for a particular entity
• ER Diagram gives a better understanding of the information to be
stored in a database
• It reduces complexity and allows database designers to build
databases quickly
• It helps to describe elements using Entity-Relationship models
• It allows users to get a preview of the logical structure of the database

15
Department of AIML ZCOER, Pune
 Database Design and ER Model

16
Department of AIML ZCOER, Pune
 Database Design and ER Model

• Components of ER Diagram
• You base an ER Diagram on three basic concepts:
• Entities
– Weak Entity
• Attributes
– Key Attribute
– Composite Attribute
– Multivalued Attribute
– Derived Attribute
• Relationships
– One-to-One Relationships
– One-to-Many Relationships
– Many-to-One Relationships
– Many-to-Many Relationships

17
Department of AIML ZCOER, Pune
 Symbols used in ER Diagram

18
Department of AIML ZCOER, Pune
 ER Diagram

Entity
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 are of two types
1.Tangible Entity – Which can be touched like car , person etc.
2.Non – tangible Entity – Which can’t be touched like air , bank account etc.
Entity Set: An Entity is an object of Entity Type and a set of all entities is
called an entity set. 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:

19
Department of AIML ZCOER, Pune
 ER Diagram

20
Department of AIML ZCOER, Pune
 ER Diagram

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.

21
Department of AIML ZCOER, Pune
 ER Diagram

Attributes
Attributes are the properties that define the entity type. For example,
Roll_No, Name, DOB, Age, Address, and Mobile_No are the attributes that
define entity type 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
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.

22
Department of AIML ZCOER, Pune
 ER Diagram
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.

23
Department of AIML ZCOER, Pune
 ER Diagram

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.

24
Department of AIML ZCOER, Pune
 ER Diagram

The Complete Entity Type Student with its Attributes can be represented as:

25
Department of AIML ZCOER, Pune
 ER Diagram

Relationship Type and Relationship Set

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.

26
Department of AIML ZCOER, Pune
 ER Diagram

The number of different entity sets participating in a relationship set is called

the 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.

27
Department of AIML ZCOER, Pune
 ER Diagram
The number of different entity sets participating in a relationship set is called
the degree of a relationship set.
3. Ternary Relationship: When there are n entities set participating in a relation,
the relationship is called an n-ary relationship.
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:
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.

28
Department of AIML ZCOER, Pune
 ER Diagram
Using Sets, it can be represented as:

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.

29
Department of AIML ZCOER, Pune
 ER Diagram

Using sets, one-to-many cardinality can be represented as:

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.

30
Department of AIML ZCOER, Pune
 ER Diagram
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.

In this example, student a1 is enrolled in b1 and b2 and b3. a2 is

enrolled by b1, b2, and b3.And a3 is enrolled in b1 and b2 and b3 So
it is many-to-many relationships.

31
Department of AIML ZCOER, Pune
 ER Diagram
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.

32
Department of AIML ZCOER, Pune
 ER Diagram

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.

33
Department of AIML ZCOER, Pune
 ER Diagram - Cardinality

34
Department of AIML ZCOER, Pune
 ER Diagram

35
Department of AIML ZCOER, Pune
 ER Diagram

36
Department of AIML ZCOER, Pune
 ER Diagram

37
Department of AIML ZCOER, Pune
 Keys
• In databases, keys are fundamental in maintaining data integrity and
organization.
• They serve as unique identifiers and establish relationships between
tables, enabling efficient data retrieval and manipulation.
• With the help of keys, users can relate tables.

38
Department of AIML ZCOER, Pune
 Keys
Primary key
• 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. We can even select License_Number and Passport_Number as primary
keys since they are also unique.
• For each entity, the primary key selection is based on requirements and
developers.
•

39
Department of AIML ZCOER, Pune
 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.

40
Department of AIML ZCOER, Pune
 Keys
3. Super key
Super keys are collections of one or more properties (columns) in database
management systems that allow a tuple (row) in a relation (table) to be distinctly
identified.
order_id customer_id product_id quantity

1 101 1 2

2 102 2 1

3 101 3 3

4 103 1 1

5 102 4 2

In this case, all three characteristics, order_id, customer_id, and product_id,

constitute a superkey. This is because the order ID, customer ID, and product ID
combined securely recognize every order.
41
Department of AIML ZCOER, Pune
 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.
• 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.

42
Department of AIML ZCOER, Pune
 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.
• For example, employee relation has two attributes, Employee_Id and PAN_No, that act
as candidate keys. In this relation, Employee_Id is chosen as the primary key, so the other
candidate key, PAN_No, acts as the Alternate key.

43
Department of AIML ZCOER, Pune
 Keys
5. Alternate key

44
Department of AIML ZCOER, Pune
 Keys
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.

45
Department of AIML ZCOER, Pune
 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.

46
Department of AIML ZCOER, Pune
Converting ER diagram into tables

47
 Converting ER diagram into tables
1. Book Book (Book_id, Title, Author, Price, Available)
Table
Column Name Data Type Constraints
Book_id INT PRIMARY KEY
Title VARCHAR NOT NULL
Author VARCHAR NOT NULL
Price DECIMAL NOT NULL
Available BOOLEAN NOT NULL

2. Publisher Table Publisher (Pub_id, Name, Address)

Column Name Data Type Constraints

Pub_id INT PRIMARY KEY
Name VARCHAR NOT NULL
Address VARCHAR NOT NULL

48
 Converting ER diagram into tables
3. Member
Table
Column Name Data Type Constraints Member (Member_id, Name, Address,
Member_date, Member_type,
Member_id INT PRIMARY KEY
Expiry_date)
Name VARCHAR NOT NULL
Address VARCHAR NOT NULL
Member_date DATE NOT NULL
Member_type VARCHAR NOT NULL
Expiry_date DATE NOT NULL

4. Published_by Table (Relationship between Book and Publisher)

Published_by (Book_id, Pub_id)
Column Name Data Type Constraints
Book_id INT FOREIGN KEY REFERENCES Book(Book_id)
Pub_id INT FOREIGN KEY REFERENCES Publisher(Pub_id)

49
 Converting ER diagram into tables
5. Borrowed_by Table (Relationship between Book and Member)

Browsed_by (Book_id, Member_id, Issue)

Column Name Data Type Constraints

Book_id INT FOREIGN KEY REFERENCES Book(Book_id)
Member_id INT FOREIGN KEY REFERENCES Member(Member_id)
Issue_date DATE NOT NULL

50
 Integrity Constraints

• 1. Domain constraints
• Domain constraints can be
defined as the definition of a
valid set of values for an
attribute.
• The data type of domain
includes string, character,
integer, time, date, currency,
etc.
• The value of the attribute
must be available in the
corresponding domain.
 Integrity Constraints

emp_id Nam Birth_ye Dept_id

• 1. Domain constraints e ar
• Consider an employee table 10001 Raja 2000 001
having emp_id, Name, 10002 Tiya 2001 002
Birth_year, Dept_id:
10003 Puja 1999 001
10004 Rohit 2002 B
• Because B is a character and
the attribute (Dept_id) only
accepts integer values, the
value B in the last row and
column violates the domain
integrity restriction.
 Integrity Constraints

emp_id Nam Birth_ye Dept_id

• 2. Entity integrity constraints e ar
• The entity integrity constraint
10001 Raja 2000 001
states that primary key value
can't be null. 10002 Tiya 2001 002

• This is because the primary key 10003 Puja 1999 001

value is used to identify Null Rohit 2002 B
individual rows in relation and if
the primary key has a null value,
then we can't identify those Not allowed
rows.
• A table can contain a null value
other than the primary key field.
 Integrity Constraints
• 3. Referential integrity constraints
• A referential integrity constraint is specified between two tables.
• In the Referential integrity constraints, if a foreign key in Table 2 refers
to the Primary Key of Table 1, then every value of the Foreign Key in
Table 2 must be available in Table 1.
• Referential integrity constraints are rules that ensure relationships
between tables remain consistent.
• This guarantees the logical connection between related tables in a
relational database.
• Maintains Consistency: Ensures relationships between tables are valid.
• Prevents Orphan Records: Avoids cases where a record in a child table
references a non-existent parent record.
• Enforces Logical Relationships: Strengthens the logical structure of a
relational database.
 Referential Integrity
• PK FK
FK
Roll-no Name Address Course-id Course-Name Roll-no
1 A Pune C1 DBMS 1
2 B Pune C2 C++ 2
3 A Mum

Referenced table-base table Referencing table

Operation in Referenced table

1. Insert – No violation- can insert as many records as needed

2. Delete – may cause violation if record is deleted from base table But not from
Referencing table
Solution – on delete cascade, on delete set null, on delete no action
3. Update - may cause violation if record is deleted from base table But not from
Referencing table
Solution – on delete cascade , on delete set null, on delete no action
 3. Referential Integrity
• PK FK
Roll-no Name Address Course-id Course-Name Roll-no
FK
1 A Pune C1 DBMS 1
2 B Pune C2 C++ 2
3 A Mum

Referenced table-base table Referencing table

Operation in Referencing table

1. Insert – may cause violation
2. Delete – No violation
3. Update - may cause violation
 Integrity Constraints
• 4. Key integrity constraints
• Key constraints ensure that certain columns or combination of
columns in a table uniquely identify each row.
• These rules are essential for maintaining data integrity and
preventing duplicate or ambiguous records.
• Why Key Constraints Are Important ?
• Prevent Duplicates: Ensure unique identification of rows.
• Maintain Relationships: Enable proper linking between tables
(via foreign keys).
• Enforce Data Integrity: Prevent invalid or inconsistent data.
 Integrity Constraints
• Enterprise Constraints
• Enterprise constraints – sometimes referred to as semantic
constraints – are additional rules specified by users or database
administrators and can be based on multiple tables.
• Here are some examples.
• A class can have a maximum of 30 students.
• A teacher can teach a maximum of four classes per semester.
• An employee cannot take part in more than five projects.
• The salary of an employee cannot exceed the salary of the
employee's manager.
 View to Get Books Available for Borrowing

• CREATE VIEW Available_Books AS

SELECT Book_id, Title, Author, Price FROM Book WHERE
Available = 'Yes';

2/17/2025 drdytdtudutftuftftftfytfytfty 59
 Schema Diagram

A schema diagram is a compelling visual representation of a database

system's structure and organization.
It functions as a blueprint for how entities, attributes, and relationships
within a database are interconnected.

It helps to understand:

Tables and Attributes: What data each table stores.

Primary Keys (PK): Unique identifiers for each record in a table.

Foreign Keys (FK): Links between tables that enforce relationships.
Relationships (1:1, 1:M, M:M): How entities interact with each other.

60
 Schema Diagram

The building blocks of a SCHEMA DIAGRAM include:

Entities: These are the objects or concepts about which data is stored.
Entities are typically represented as rectangles.

Attributes: These are the properties or characteristics of entities. Attributes

are usually represented as ovals connected to their respective entities or as
lists inside the entity rectangle.

Relationships: These show how two or more entities interact with each other.
Relationships are illustrated by a line connecting the related entities.

Cardinality: This defines the numerical attributes of the relationship between

two entities. The cardinality could be one-to-one, one-to-many, or
many-to-many.
61
Schema Diagram

62