Course Code: CS404PC

Unit -2 Part-1
DATABASE MANAGEMENT
SYSTEMS
By B. Lokesh Joel
 Unit-2:
• Introduction to the Relational Model: • Relational Algebra,
• Integrity constraint over relations,
• Tuple relational Calculus,
• enforcing integrity constraints,

• querying relational data, • Domain relational calculus

• logical database design,

• introduction to views,

• destroying/altering tables and views.

The Relational Model
▪ Definition of a Table
– A table is an arrangement of words, numbers, or signs in parallel columns
to present facts or relationships concisely.
– This tabular representation enables an easy understanding of the database
contents.
 Introduction to the Relational Model
▪ Proposed by E.F. Codd in 1970.
▪ Before this, databases followed older hierarchical and network models.
▪ The relational model revolutionized database systems, replacing older
models.
▪ Early relational DBMS research was conducted at IBM and UC-Berkeley
in the mid-1970s.
▪ Today, relational DBMS is the foundation for IBM DB2, Oracle, Sybase,
SQL Server, MySQL, FoxBase, and Paradox.
▪ Relational databases dominate the industry, representing a multibillion-
dollar market.
 Advantages of the Relational Model
▪ Simplicity & Elegance: A database is a collection of relations (tables with
rows and columns).

▪ User-Friendly: Even novice users can understand and query databases easily.

▪ Efficient Querying: High-level query languages allow for easy data

manipulation.

▪ Better Data Representation: Simple, structured format.

▪ Logical & Physical Data Independence: Data can be modified without

affecting applications.
 SQL (Structured Query Language)
▪ Developed for System-R, IBM’s pioneering relational DBMS.
▪ Most widely used query language for relational databases.
▪ Used for creating, manipulating, and querying relational
DBMSs.
 SQL (Structured Query Language)
▪ SQL Standards
– SQL-86 (ANSI 1986): First SQL standard.
– SQL-89 (ANSI 1989): Minor revision.
– SQL-92 (ANSI & ISO 1992): Major revision, widely supported.
– SQL:1999: Extension of SQL-92, introduces new features.
 SQL (Structured Query Language)
▪ Importance of SQL Standards
1. Consistency Across Different Databases
• SQL is used by many database systems like MySQL, Oracle, and SQL Server.
• Standards make sure that the basic SQL commands work the same way in all systems.

2. Easy Comparison Between Different SQL Versions

• If different databases follow the same standard, we can easily compare their features.
• This helps users choose the best system for their needs.

3. Better Portability (Moving Data Between Systems)

• If a database uses non-standard SQL features, it may not work in another system.
• Following SQL standards ensures that the same queries work in different databases without modification.
Introduction to the Relational Model
• The main construct for representing data in the relational model
is a relation.
• A relation consists of:
• Relation Schema: Defines structure (column names & types).
• Relation Instance: A table containing data (rows & columns).
 Relation Schema(Entity Type)
▪ Specifies:
– Relation Name.
– Field Names (Attributes/Columns).
– Domain of each field (data type or set of allowed values).

– sid has domain string (set of character strings).

– age has domain inter (whole numbers).
– gpa has domain real (decimal numbers).
 Relation Instance(Entity)
▪ A relation instance is a set of
tuples (records/rows).
▪ Each tuple has the same
number of fields as the
relation schema.
Key Properties of a Relation Instance
1. Uniqueness: No two rows can be identical.
2. Order of Rows: The order in which rows are stored is not
important.
3. Order of Columns:
– If field names are used → order does not matter.
– If fields are referenced by position → order does matter.
State of a Relation in the Relational Model
▪ A relation in a database exists in two forms:
– Intension (Schema)
– Extension (Instance)
State of a Relation in the Relational Model
▪ A relation in a database exists in two forms:
– Intension (Schema)
• The structure of a relation, also known as its schema or entity type.
• Represents: The design of the table, including column names and
data types.
• Static: The schema does not change frequently.
• Example:

• Here, the table Students is the

schema, defining attributes (sid,
name, etc.) and their data types.
 State of a Relation in the Relational Model
▪ A relation in a database exists in two forms:
– Extension (Instance)
• The actual data stored in a relation at a given moment, also called an instance of the table.
• Represents: The current state of a table with all the rows (tuples) present.
• Dynamic: The extension changes as rows are added, deleted, or updated.
• Example (Instance of Students Table)
• The rows (tuples) in this table represent the extension at a specific moment.
 Domain Constraints
▪ A domain is a set of valid values for a field.
▪ Domain constraints ensure that values in a column belong to a specific
domain.
– Example: In the Students table, the age field must only contain integers.

▪ Formal Definition
– Let R(f1:D1, ..., fn:Dn) be a relation schema.
– Each fi (field) has a domain Di with values Domi.
– An instance of R is a set of tuples satisfying:
 Domain Constraints
▪ Atomic Values:
– Each attribute value must be atomic (indivisible).
– Example (Valid Atomic Value):
• age = 21 (Single integer value)
• phone_numbers = {9876543210, 9123456789} (Multiple values in one attribute)

– A relational database should not store lists or nested data in a single column.

▪ Flat File Structure:

– A relational table must have a flat structure, meaning:
– No multi-valued attributes (e.g., storing multiple phone numbers in one column).
– No nested or composite attributes. (e.g., storing a list of addresses inside a single attribute).
– Instead, such data should be normalized into separate tables using foreign keys.
 Degree (Arity) and Cardinality
▪ Degree (Arity): Number of fields (columns) in a relation.
• Cardinality: Number of tuples (rows) in a relation instance.
▪ Example
– For the Students relation instance:
• Degree = 5 (since there are 5 columns).
• Cardinality = 6 (since there are 6 rows).
 Relational Database
▪ Example: University Database
▪ A relational database is a
– Contains multiple relations:
collection of relations.
• Students(sid, name, login, age, gpa)
▪ Each relation has a distinct • Faculty(fid, name, dept)
• Courses(cid, name, credits)
name.
• Enrolled(sid, cid, grade)
▪ The relational database • Teaches(fid, cid)
• Rooms(room_id, capacity)
schema consists of schemas for
• Meets_In(cid, room_id, time)
all relations in the database.
▪ Each relation instance in the database
must satisfy its domain constraints.
Creating and Modifying Relations Using SQL-92
• SQL-92 uses the term table instead of relation.
• The Data Definition Language (DDL) in SQL supports:
• Creation of tables.
• Modification of tables.
• Deletion of tables.
 Creating Tables in SQL
▪ CREATE TABLE is used to define a new table.
▪ Example: Creating the Students Table

• sid, name, login, age, and gpa are columns

(attributes) of the table.
• Data types:
• CHAR(n): Fixed-length character string.
• INTEGER: Whole numbers.
• REAL: Decimal numbers.
 Inserting Data into a Table
▪ INSERT INTO is used to add new tuples (records) to a table.

▪ Column names can be omitted if values are inserted in the correct

order:

▪ Best practice: Always specify column names for clarity.

 Deleting Data from a Table
▪ DELETE FROM is used to remove tuples from a table.

▪ Deletes all records where name = 'Smith'.

 Updating Data in a Table
▪ UPDATE modifies values in existing tuples.
– Example: Incrementing Age & Decreasing GPA
• WHERE clause: Selects tuples to update.
• SET clause: Defines changes.
• The old values are used before the
modification.

– Example: Reducing GPA of Students with GPA ≥ 3.3

 Integrity Constraints (ICs)
▪ Integrity constraints (ICs) help ensure that only correct and valid data is stored
in a database.
▪ A database instance that satisfies all ICs is called a legal instance.
▪ DBMS ensures ICs by:
– Checking ICs when data is inserted or modified.
– Rejecting changes that violate ICs.
– Making compensating changes (in some cases) to maintain consistency.

▪ Key Constraints
▪ Foreign Key Constraints
▪ General Constraints
 Key Constraints
▪ A key constraint ensures that each
row in a table is uniquely identifiable.
▪ A candidate key is a minimal set of
fields that uniquely identifies a tuple. • Key Constraints in this table:
• sid is a candidate key (no two students
▪ A superkey is any set of attributes have the same sid).
• {login, age} is another candidate key
that contains a candidate key. (students may share a login or age, but
not both).
▪ Every relation must have at least one • {sid, name} is a superkey, but not a
key. candidate key because sid alone is
sufficient.
https://www.geeksforgeeks.org/super-key-in-dbms/
 Super Key
▪ A super key is a set of attributes that uniquely identifies a tuple (row) in a relation.
▪ It may contain extra attributes that are not necessary for unique identification.
▪ Any Superset of a Super Key is Also a Super Key
▪ Example:
– Consider the Students table:

• Super Keys:
• {sid}
• {sid, name}
• {sid, name, login}
• {login, age} (assuming login and age together
uniquely identify a student)
 Super Key – Includes Primary Key and Candidate Keys:
• Every primary key and candidate key is a super
▪ Key Features of Super Key
key, but not all super keys are primary keys or
– Uniqueness: candidate key.
• A super key ensures that every row in a – Foundation for Database Design:
table is uniquely identified and prevents
duplicate records. • Super keys are essential for determining
candidate keys and ensuring data integrity in a
– One or More Attributes:
database.
• It can consist of a single column or a
combination of multiple columns.
– Not Necessarily Minimal:
• A super key may include extra attributes
that are not required for uniqueness,
unlike a candidate key.

https://www.geeksforgeeks.org/super-key-in-dbms/
 Super Key
{A1} ➔ {A1, A2}, {A1, A3}, {A1, A4}
A1 A2 A3 A4 {A1, A2}➔{A1, A2, A3}, {A1, A2, A4}, {A1, A2, A3, A4}
1 2 5 4 {A1,A3}➔{A1, A3, A4}
2 2 6 4 {A2, A3}➔{A2, A3, A4}
3 3 5 5
{A3, A4}
4 4 7 5
 Key (Minimal Super Key)
▪ A key is a minimal super key, meaning:
– It uniquely identifies a tuple.
– No extra attributes can be removed while still maintaining uniqueness.
– Example:
• From the super keys above, minimal keys are:
• {sid} (Minimal and unique)
• {login, age} (If login and age together uniquely identify a student)
• But {sid, name} is not a key because name is unnecessary (sid alone is enough).
 Candidate Key
▪ If a relation has more than one key, each of them is called a candidate
key.
– Example:
• In the Students table, we identified:
• {sid}
• {login, age}
• Since both uniquely identify a tuple, they are candidate keys.
https://mycareerwise.com/content/calculate-super-key/content/exam/nta-net/computer-science
Note: Number of super keys = 𝟐𝒏−𝒌
where “n” is the number of attributes in the
Relation R and “k” is the number of
attributes in the Candidate Key
• Let a Relation R have attributes {a1,a2,a3} and a1 is the candidate key. Then
how many super keys are possible?

Number of super keys = 𝟐𝒏−𝒌 = 𝟐𝟑−𝟏 = 𝟐𝟐

• Let a Relation R have attributes {a1, a2, a3,…,an}. Find Super key of R.
Maximum Super keys = 2n – 1.

• Let a Relation R have attributes {a1, a2, a3,…, an} and the candidate key is “a1 a2 a3”
then the possible number of super keys?
Number of possible super keys is 2(N-3).

https://www.geeksforgeeks.org/number-of-possible-superkeys-in-dbms/
• Let a Relation R have attributes {a1, a2, a3,…, an} and the candidate keys are “a1”, “a2”
then the possible number of super keys?
Let a Relation R have attributes {a1, a2, a3,…,an} and the candidate keys are “a1”, “a2”,
“a3” then the possible number of super keys?
Let a Relation R have attributes {a1, a2, a3,…,an} and the candidate keys are “a1”, and
{a1,a2} then the possible number of super keys?
 Primary Key
▪ Among the candidate keys, one key is chosen as the primary key for database
implementation.
▪ It is the main key used for referencing records.
▪ Example:
– If {sid} and {login, age} are candidate keys, we choose {sid} as the primary key because it is:
• Simple (only one attribute)
• Efficient (indexed in most databases)
Foreign Key Constraints
• A foreign key (FK) is an attribute in one relation that refers to the primary
key (PK) in another relation.
• Ensures referential integrity, meaning:
• A value in the foreign key column must exist in the referenced table.
• Prevents orphaned records (references to non-existent entities).
Foreign Key Constraints
 Referential Integrity Enforcement
▪ Violations of Foreign Key Constraints
– Invalid Insertion

• Error: "Cannot insert or update because sid=55555 does not exist in Students.“

– Invalid Deletion

• Error: "Cannot delete sid=53666 because it is referenced in Enrolled."

 Referential Integrity Enforcement
▪ Violations of Foreign Key Constraints
– Valid Deletion with ON DELETE CASCADE
Referential Integrity Enforcement
https://gateoverflow.in/1399/gate-CSB-2005-question-76
 General Constraints
▪ General constraints go beyond basic constraints like domain, primary key, and foreign key
constraints.

▪ These constraints ensure data consistency and correctness for specific requirements.

▪ Used when standard constraints are not sufficient.

▪ Example :
– Students must be at least 16 years old.
• If we enforce this rule, students younger than 16 should not be inserted.
• This modifies the Students table and removes underage students.
 General Constraints
▪ Extended Domain Constraints
– Example: The rule that students must be older than 16 is an extended domain constraint.
– Why? It defines acceptable values beyond the standard integer type.
– It restricts input values more strictly than a standard data type.
– Another Example: Every student older than 18 must have a GPA greater than 3.

▪ Implementation of General Constraints

– Implemented in modern databases using:
– Table Constraints → Applied to a single table and checked on modification.
– Assertions → Applied across multiple tables and checked when any related table is modified.
Enforcing Integrity Constraints
▪ Integrity Constraints (ICs) and Their Enforcement

• ICs ensure database correctness and are checked when a

relation is created or modified.

• Common ICs:
• Domain Constraints → Ensures valid data types.
• Primary Key Constraints → Ensures uniqueness & non-null values.
• Unique Constraints → Ensures unique values.
• Foreign Key Constraints → Ensures valid references.
 Handling Violations in SQL
▪ INSERT Violations
– INSERT operations fail if they violate constraints like primary key, unique, foreign key,
or domain constraints.
Violation Type Example Error Message Solution
INSERT INTO Students (sid,
"Duplicate entry for primary key Ensure sid is unique before
Primary Key Violation name) VALUES (53688, 'Mike');
sid." insertion.
(Duplicate sid)

INSERT INTO Students (sid, "Primary key column sid cannot be

Primary Key NULL Violation Ensure sid has a valid value.
name) VALUES (NULL, 'Mike'); NULL."

INSERT INTO Enrolled (cid, sid)

"Cannot add or update: FOREIGN Ensure foreign key references an
Foreign Key Violation VALUES ('CS101', 9999); (sid=9999
KEY constraint fails." existing primary key.
does not exist in Students)

INSERT INTO Students (sid, name,

"Data type mismatch: age must be Ensure values match the expected
Domain Constraint Violation age) VALUES (1001, 'Alice',
an INTEGER." data type.
'twenty'); (Age must be INTEGER)
 DELETE Violations
▪ DELETE operations fail if they violate referential integrity constraints

Violation Type Example Error Message Solution

DELETE FROM "Cannot delete or
Use ON DELETE
Foreign Key Students WHERE update a parent row:
CASCADE to delete
Violation sid = 1001; (sid exists FOREIGN KEY
dependent records.
in Enrolled) constraint fails."
DELETE FROM
Manually delete
Deleting Students WHERE "Referential
dependent rows
Referenced Data sid = 1002; (Student integrity violation."
from Enrolled first.
has enrollments)
DELETE Violations
▪ Using ON DELETE CASCADE

▪ This automatically deletes enrollments when a student is deleted.

 UPDATE Violations
• UPDATE operations fail if they result in constraint violations.

Violation Type Example Error Message Solution

UPDATE Students SET sid =

"Duplicate entry for PRIMARY
Primary Key Violation 50000 WHERE sid = 53688; Ensure unique primary keys.
KEY."
(sid=50000 already exists)

UPDATE Enrolled SET sid =

Updating a Foreign Key to 9999 WHERE sid = 53650; "Cannot update: FOREIGN Ensure the new value exists in
Non-Existent Value (sid=9999 does not exist in KEY constraint fails." the referenced table.
Students)

Updating Data Type UPDATE Students SET age = "Data type mismatch: age Ensure correct data type
Violation 'twenty' WHERE sid = 1001; must be an INTEGER." before update.
 UPDATE Violations
▪ Using ON UPDATE CASCADE

– This automatically updates sid in Enrolled when sid in Students is updated.

VIEW Handling for Integrity Violations
▪ Views help restrict access and prevent constraint violations.
▪ Creating a View to Prevent
– Violations in Enrolled Table
Benefits of Using Views:
1. Prevents constraint violations by filtering only valid data.
2. Ensures referential integrity in queries.
3. Restricts access to prevent unauthorized modifications.
 Constraint Type Definition INSERT Violation DELETE Violation UPDATE Violation Solution

INSERT INTO Students UPDATE Students SET

Ensures values match a
(sid, age) VALUES (1001, gpa = 5.5 WHERE sid = Ensure values match
Domain Constraint defined data type or (Not applicable)
'twenty'); (Age should be 1001; (GPA must be data type and range.
range.
an INTEGER) between 0.0 - 4.0)

INSERT INTO Students UPDATE Students SET

Ensures uniqueness of
(sid, name) VALUES sid = 1002 WHERE sid = Ensure primary key
Key Constraint primary or candidate (Not applicable)
(1001, 'Bob'); (sid=1001 1001; (sid=1002 already values are unique.
keys.
already exists) exists)

INSERT INTO Students UPDATE Students SET

Entity Integrity Ensures primary keys (sid, name) VALUES sid = NULL WHERE sid Ensure primary key
(Not applicable)
Constraint cannot be NULL. (NULL, 'Charlie'); (sid = 1003; (Primary key always has a value.
cannot be NULL) cannot be NULL)

INSERT INTO Enrolled DELETE FROM UPDATE Enrolled SET

Ensures foreign keys Ensure referenced values
Referential Integrity (sid, cid) VALUES (9999, Students WHERE sid = sid = 9999 WHERE sid =
reference valid primary exist or use ON DELETE
Constraint 'CS101'); (sid=9999 does 1001; (sid=1001 is 1001; (sid=9999 does not
keys. CASCADE.
not exist in Students) referenced in Enrolled) exist in Students)
 Querying Relational Data
▪ Relational Database Query:
– A query retrieves data from a relation based on specified conditions.
– The result is a new relation containing selected tuples.

▪ Query Language:
– SQL (Structured Query Language) is commonly used for querying relational databases.
– Example Query (Students younger than 18):

• Retrieves all students with age less than 18.

• The * symbol retains all fields of selected tuples.
 Querying Relational Data
▪ Understanding Queries in SQL
– Selection (WHERE clause):
• Filters tuples based on conditions.
• Example: S.age < 18 selects rows where age is less than 18.

– Projection (SELECT clause):

• Retrieves specific fields from tuples. – Produces the result:
• Example:

– Order of Operations:
• Selection is applied first to filter rows.
• Projection is applied next to remove unnecessary fields.
 Querying Relational Data
▪ Joining Multiple Relations
– Example Query (Students who got an ‘A’ in a course):

– Uses a join to combine Students and Enrolled relations.

– Filters students who got an A in any course.
 Querying Relational Data
▪ SQL Type Compatibility
– Domain Restrictions:
• Comparisons should be between values of the same type.
• Example:
• S.age < 18 (Valid: age is an integer).
• S.age = S.sid (Invalid: age is an integer, sid is a string).

– SQL-92 vs. SQL-1999:

• SQL-92 does not allow distinguishing similar-looking values from different domains.
• SQL-1999 introduces distinct types to differentiate such values.
 Logical Database Design: ER to Relational
▪ The ER model provides a high-level conceptual design for databases.
▪ The relational model translates ER diagrams into relations (tables).
▪ SQL-92 can enforce some constraints, but complex constraints may
be expensive.
 Entity Sets to Tables
▪ Mapping Entities to Relations
– Each entity set is converted into a table.
– Attributes of an entity set become columns in the table.
– The primary key of the entity set becomes the primary key of the table.
 Entity set with a composite attribute
▪ In ER modeling, an attribute is composite if it can be divided into subparts.
▪ While converting an ER diagram to a relational model, composite attributes are
not directly included.
▪ Instead, their components are treated as individual attributes in the relational
schema.
 Entity set with multivalued attributes
▪ Understanding Multivalued Attributes
– A multivalued attribute means an attribute can have multiple values for a single
entity.
– Example: An Employee entity with a PhoneNo attribute where one employee can
have multiple phone numbers.
Solution: Splitting into Two Relations
• Create two separate tables:
• Primary Table: Contains key attribute and
all simple attributes.
• Secondary Table: Contains key attribute
and the multivalued attribute.
Entity set with multivalued attributes
Translation of a relationship into a relation
▪ Conversion of one-to-many relationship
▪ Conversion of one-to-many relationship
• One entity (e.g., Department) can be associated with
multiple instances of another entity (e.g., Employee).
• This means:
• An employee can belong to at most one
department.
• A department can have multiple employees.

Emp_id (PK) Emp_name Emp_age Dept_id (FK) Dept_id (PK) Dept_name

101 John 25 10 10 HR
102 Alice 30 20 20 IT
103 Bob 28 10 30 Finance

or
Emp_id (PK) Emp_name Emp_age Dept_id (PK) Dept_name Emp_id (PK) Dept_id (PK)
101 John 25 10 HR 101 10
102 Alice 30 20 IT 102 20
103 Bob 28 30 Finance 103 30
 • A one-to-many relationship occurs
when one entity is associated with
multiple instances of another entity.
• In this case:
• One Faculty can teach multiple
Courses.
• Each Course is taught by only one
Faculty.

Faculty_id Faculty_name Faculty_age Course_id Course_name Faculty_id (FK)

CSB101 Database F101
F101 Dr. Smith 45
CSB102 AI & ML F102
F102 Prof. John 50 Computer
CSB103 F101
Networks
F103 Dr. Alice 40 CSB104 Cyber Security F103
▪ Conversion of one-to-one relationship
• A one-to-one (1:1) relationship means
that one entity is associated with only
one instance of another entity.
• In this case (if applied to Faculty-
Course):
• One Faculty teaches only one
Course.
• Each Course is taught by only one
Faculty.

Faculty_id Faculty_name Faculty_age Course_id Course_name

CSB101 Database
F101 Dr. Smith 45
CSB102 AI & ML
F102 Prof. John 50
CSB103 Computer Networks
F103 Dr. Alice 40 CSB104 Cyber Security
Approach 1: Store Faculty_ID in Course Table

Course_id (PK) Course_name Faculty_id (FK, Unique)

CSB101 Database F101
CSB102 AI & ML F102
CSB103 Cyber Security F103

Approach 2: Store Course_ID in Faculty Table

Course_id (FK,
Faculty_id (PK) Faculty_name Faculty_age
Unique)
F101 Dr. Smith 45 CSB101
F102 Prof. John 50 CSB102
F103 Dr. Alice 40 CSB103
Approach 3: Creating a Separate Table for One-to-One (1:1) Relationship

Faculty_Course Table (Mapping Table)

Faculty_id (PK, FK) Course_id (PK, FK)
F101 CSB101
F102 CSB102
F103 CSB103

• Faculty_id references the Faculty Table (PK & FK).

• Course_id references the Course Table (PK & FK).
• Both columns are Primary Keys (PK) ensuring a one-to-one mapping.
▪ Conversion of many-to-many relationship
• A many-to-many (M:N) relationship
means that one entity can be
associated with multiple instances of
another entity and vice versa.
• In this case:
• One Faculty can teach multiple
Faculty_id (PK) Faculty_name Faculty_age Courses.
F101 Dr. Smith 45 • One Course can be taught by
F102 Prof. John 50 multiple Faculties.
F103 Dr. Alice 40

Course_id (PK) Course_name

CSB101 Database
CSB102 AI & ML
CSB103 Cyber Security
▪ Conversion of many-to-many relationship

Faculty_Course Table (Junction Table)

Faculty_id (FK, PK) Course_id (FK, PK)
F101 CSE101
F101 CSE102
F102 CSE101
F102 CSE103
F103 CSE103

• Faculty_id references Faculty Table (PK & FK).

• Course_id references Course Table (PK & FK).
• Both columns act as a Composite Primary Key (PK) ensuring that a faculty-course
pair is unique.
One-to-One (1:1) Relationship with Total Participation
• One-to-One (1:1) Relationship: Each faculty teaches at
most one course, and each course is taught by at most
one faculty.
• Total Participation Towards Course Table:
• Every course must be assigned a faculty (No
course can be left without a faculty).
• Not every faculty must have a course (Some
faculty members might not be assigned any
Since every course must have a faculty, but not every course).
faculty must have a course, we store the Faculty_id in • This is represented by a bold line (total
the Course Table. participation) on the course side in the ER
diagram.
Course Table (Total Participation)
Faculty_id (FK,
Course_id (PK) Course_name Unique, NOT
NULL) • Faculty_id is a Foreign Key referencing
Faculty Table and is UNIQUE.
CSE101 Database F101
• Faculty_id is marked as NOT NULL to enforce
CSE102 AI & ML F102 total participation.
CSE103 Cyber Security F103 • This ensures every course has a faculty.
Why Store Faculty_id in Course Table?
• Since every course must be assigned to a faculty, Faculty_id is placed in the Course
Table.
• NOT NULL Constraint on Faculty_id ensures total participation.
• Faculty members without courses do not need an entry in the Course table,
allowing partial participation on the faculty side.
Question:
Given the basic ER and relational models, which of the following is
INCORRECT?
1. An attribute of an entity can have more than one value.
2. An attribute of an entity can be composite.
3. In a row of a relational table, an attribute can have more than one value.
4. In a row of a relational table, an attribute can have exactly one value or a NULL
value.

Option 3 is Incorrect
Explanation of Each Option:
1. An attribute of an entity can have more than one value ( Correct)
• In ER models, an entity can have multivalued attributes.
• Example: An Employee entity having multiple Phone Numbers.
2. An attribute of an entity can be composite ( Correct)
• A composite attribute is an attribute that can be divided into sub-parts.
• Example: Full Name can be divided into First Name and Last Name.
3. In a row of a relational table, an attribute can have more than one value ( Incorrect)
• In the Relational Model, an attribute must be atomic (it cannot have multiple values).
• This follows First Normal Form (1NF), which states that each attribute in a row must contain
a single, atomic value.
• Multivalued attributes are not allowed in relational tables.
4. In a row of a relational table, an attribute can have exactly one value or a NULL value (
Correct)
• In the Relational Model, an attribute must contain either:
• A single value (Atomic Value).
• A NULL value (if no data is available).
• Find the minimum number of tables required to represent the given ER diagram in
relational model-

1 N N M

• Minimum Number of Tables Required = 4

1. E1 (Entity Table)
2. E2 (Entity Table)
3. E3 (Entity Table)
4. R2 (Relationship Table for M:N relationship)
• Find the Maximum number of tables required to represent the given ER diagram in
relational model-

1 N N M

• Maximum Number of Tables Required = 5

1. E1 (Entity Table)
2. E2 (Entity Table)
3. E3 (Entity Table)
4. R1 (Separate Relationship Table for 1:N)
5. R2 (Relationship Table for M:N)
 N-ary relationships (>2)
[ER diagram in relational model]

A11 A12 A13 A21 A22 A23

Entity-1 Entity-2

Entity-1

A31 A33
A32
N-ary relationships (>2)
[ER diagram in relational model]
A11 A12 A13 A21 A22 A23

A31 A32 A33 A11 A21 A31

• Find the minimum number of tables required to represent the given ER diagram in
relational model-

Dept_id Dept_Name Emp_id Emp_name

1 1 Department
Department
Head

Entities:
1. Department → Attributes: (Dept_id, Dept_Name)
2. Department Head → Attributes: (Emp_id, Emp_Name)
Minimum Number of
Relationship: Tables Required = 1.
• One-to-One (1:1) Relationship
• Total Participation on Both Sides:
• Each Department must have exactly one Department Head.
• Each Department Head must be assigned to exactly one Department.
This means every record in Department must have a matching record in Department Head, and vice versa.
• Find the minimum number of tables required to represent the given ER diagram in
relational model-

Dept_id Dept_Name Emp_id Emp_name

1 1 Department
Department
Head

Minimum Number of
Tables Required = 1.
 • Find the Maximum number of tables required to represent the given ER diagram in
relational model-

Dept_id Dept_Name Emp_id Emp_name

1 1 Department
Department
Head

• Maximum Number of Tables for One-to-One (1:1) Relationship with Total Participation on Both Sides
• Since each department must have exactly one department head, and each department head must belong
to exactly one department, the total participation constraint must be enforced.
• To maximize normalization and maintain entity integrity, we use three tables:
• Department Table (Stores department details) Maximum Number of
• Department_Head Table (Stores department head details) Tables Required = 3.
• Department_Head_Assignment Table (Stores the relationship between department and department
head with total participation)
• Find the Maximum number of tables required to represent the given ER diagram in
relational model-

Dept_id Dept_Name Emp_id Emp_name

1 1 Department
Department
Head
• Find the minimum number of tables required to represent the given ER diagram in
relational model

A C A B X Y A

• Minimum Number of Tables Required = 3

• Maximum Number of Tables Required = 4

https://testbook.com/question-answer/find-minimum-number-of-tables-required-for-convert--5ed8d2cef60d5d2aa46d83a1
Attributes to relationship : one to many
relationship
Attributes to relationship : one to many
relationship
• The given ER diagram represents the "Work for"
relationship between Employee and Department,
where:
• Each employee belongs to only one department.
• One department can have multiple employees.

Table Attributes Primary Key Foreign Key

Emp_id, Emp_name,
Dept_id →
Employee Emp_age, Dept_id, Emp_id
Department
since
Department Dept_id, Dept_name Dept_id -
Attributes to relationship : one to many
relationship
• The given ER diagram represents the "Work for"
relationship between Employee and Department,
where:
• Each employee belongs to only one department.
• One department can have multiple employees.

Table Attributes Primary Key Foreign Key

Emp_id, Emp_name,
Employee Emp_id -
Emp_age
Department Dept_id, Dept_name Dept_id -
Emp_id → Employee,
Emp_id, Dept_id,
Works_For Emp_id Dept_id →
since
Department
Attributes to relationship : one to one
relationship
 Attributes to relationship : one to one
relationship

• The given ER diagram represents the "Work for" relationship between Employee and Department,
where:
• Each employee belongs to exactly one department.
• Each department has exactly one employee.
• Since this is a one-to-one (1:1) relationship, we can implement it in two ways.
 Attributes to relationship : one to one
relationship
• Relational Schema
• We need to create two tables (instead of three, as in one-to-many relationships):
• Approach 1: Add Foreign Key to One Table (Recommended)
• Since each department has one employee, we can add Emp_id as a foreign key in the Department
table.
 Attributes to relationship : one to one
relationship
• Alternative Approach: Create a Separate Relationship Table
• If we want a strict separation of entities and relationships, we can use a separate Works_For table.
Attributes to relationship : many to many
relationship
 Attributes to relationship : many to many
relationship

• The given ER diagram represents the "Work for" relationship between Employee and Department,
where:
• An employee can work for multiple departments.
• A department can have multiple employees.
• The attribute "since" represents when the employee started working for the department.
• Since this is a many-to-many (M:N) relationship, we need an additional table to capture this
relationship.
 Attributes to relationship : many to many
relationship

Table Attributes Primary Key Foreign Key

Emp_id, Emp_name,
Employee Emp_id -
Emp_age
Department Dept_id, Dept_name Dept_id -

Emp_id → Employee,
Works_For Emp_id, Dept_id, since (Emp_id, Dept_id)
Dept_id → Department
 Relationship Sets (without Constraints) to
Tables
▪ A relationship set, like an entity set, is mapped to a relation (table) in the
relational model.
▪ When there are no key or participation constraints, each participating entity
must be uniquely identifiable.
▪ The relation includes:
– Primary key attributes of each participating entity (stored as foreign keys).
– Descriptive attributes of the relationship set.

▪ Superkey and Candidate Key in Relationship Sets

– The set of all foreign keys together forms a superkey for the relationship relation.
– If no key constraints exist, this set of attributes serves as a candidate key.
Relationship Sets (without Constraints) to
Tables
Relationship Sets (without Constraints) to
Tables
 Translating Relationship Sets with Key
Constraints
▪ Understanding Key Constraints in
Relationship Sets
– If a relationship set involves n entity sets,
some of them may have key constraints
(indicated by arrows in the ER diagram).
▪ Example Scenario: Manages Relationship
– A key constraint means that one entity
uniquely determines the relationship. – Each department has at most one manager.

– In such cases, the primary key of one of the – This means that did (Department ID) alone is
participating entities can be used as the sufficient as a primary key for the relationship table.

primary key for the relationship table. – ssn (Employee ID) is not part of the primary key
because it does not uniquely determine the
relationship.
 Translating Relationship Sets with Key
Constraints
▪ First Approach: Using a Separate Relationship Table
– The Manages relationship is stored as a separate table with:
• did (Department ID) as Primary Key (because each department has at most one manager).
• ssn (Manager's Employee ID) as a Foreign Key.
• since (Start date of management role).
 Translating Relationship Sets with Key
Constraints
▪ Second Approach: Merging Relationship Information into One Table
– Instead of creating a separate Manages table, we add manager details directly to the
Departments table.
– Since each department has at most one manager, we store:
– ssn (Manager’s Employee ID) as a foreign key in Departments.
– since (Start date of management role) as an attribute of Departments.
 Translating Relationship Sets with Key
Constraints
▪ Comparison of the Two Approaches
Approach Pros Cons
Requires JOINs to retrieve
Separate Table for
Avoids NULL values department-manager
Manages
details
May waste space if
Merging into Dept_Mgr Simplifies queries, avoids
departments have no
Table JOINs
managers (NULL values)

• If frequent queries involve finding department managers, the merged approach is

better.
• If space is a concern, the separate table approach is preferred.
 Translating Relationship Sets with
Participation Constraints
▪ Understanding Participation Constraints
– Participation constraints specify whether all
instances of an entity must participate in a
relationship.
– Total Participation: Every instance of an
entity must be related to at least one
instance of another entity.
– Partial Participation: Some instances of an
entity may not be related to any instance of
another entity.
 Translating Relationship Sets with
Participation Constraints
▪ Manages and Works_In Relationships
▪ Manages Relationship (Key + Total Participation
Constraint)
– Key Constraint: Each department has at most one
manager.
– Total Participation: Every department must have a
manager.

▪ Works_In Relationship (Total Participation

Constraint)
– Every department must have employees (Total
participation of Departments in Works_In).
– Every employee must work in at least one department
(Total participation of Employees in Works_In).
 Translating Relationship Sets with
Participation Constraints
▪ Separate Table for Dept_Mgr (Manages
Relationship)

• Key Constraint: did is the primary key, ensuring one manager

per department.
• Total Participation: ssn CANNOT be NULL, meaning every
department must have a manager.
• ON DELETE NO ACTION: Ensures an employee (manager)
cannot be deleted while they are managing a department.
 Translating Relationship Sets with
Participation Constraints
▪ Ensuring Total Participation in Works_In

▪ Challenge
– The Works_In table must ensure every department
appears in the relationship.
– Solution: Use an assertion or table constraints, which
SQL-92 does not support efficiently.

• NOT NULL on ssn and did ensures total participation.

• Every department (did) must have employees.
• Every employee (ssn) must work in at least one department
 Identifying Relationships
Translating Weak Entity Sets

Name Age Type of

Relative Emp_id Emp_name

Relative Employee

of an
Emp_id Name Age Type_of_Relative
Emp_id Emp_name
E101 John 45 Father E101 Michael
E102 Alice 38 Spouse E102 Sarah
E103 David 50 Brother E103 David
E104 Emma
E104 Sophia 30 Sister
 Translating Weak Entity Sets
▪ What is a Weak Entity Set?
– A weak entity set is an entity set that
does not have a sufficient primary key
on its own.
– It always participates in a one-to-many
relationship with a strong entity set
(the owner).
– It has a partial key (also called a
discriminator) that identifies unique
instances of the weak entity within the
owner entity.
 Translating Weak Entity Sets
▪ Key Characteristics of Weak Entities
– No Primary Key: It cannot be uniquely
identified without including the primary key of
the owner entity.
– Total Participation: Every weak entity must
be associated with an owner entity.
– Key Constraint: Each weak entity is
associated with only one owner entity.
– Deletion Dependency: If the owner entity is
deleted, all related weak entities must also be
deleted (CASCADE DELETE is required).
 Translating Weak Entity Sets
▪ Example: Dependents (Weak
Entity)
– Consider the Dependents weak entity,
where:
• Employees (Owner Entity) have dependents (Weak
Entity).
• Each Dependent is uniquely identified by:
• The name of the dependent (pname)
• The SSN of the employee (ssn)
• If an employee is deleted, all their dependents must
be deleted.
 Translating Weak Entity Sets
Explanation of Constraints
Constraint Purpose
Ensures that each dependent is uniquely identified within an
PRIMARY KEY (pname, ssn)
employee (because pname alone is not unique).

FOREIGN KEY (ssn) REFERENCES Employees Links each dependent to an existing employee.

Ensures that if an employee is deleted, all dependents

ON DELETE CASCADE
associated with that employee are also deleted.

Since ssn is part of the primary key, it cannot be NULL,

Total Participation
ensuring that every dependent is associated with an employee.
 Translating Class Hierarchies (ISA Hierarchies)
▪ Understanding ISA Hierarchies
– ISA (Inheritance) Hierarchies allow entities
to be classified into sub-entities (subclasses)
while inheriting attributes from a
superclass.
– In the given ER model, we have:
• Superclass: Employees
• Subclasses: Hourly_Emps and Contract_Emps
• ISA Relationship: Each Hourly_Emps and
Contract_Emps inherits attributes from
Employees.
 Translating Class Hierarchies (ISA Hierarchies)
▪ Two Approaches to Mapping ISA Hierarchies to
Tables
– Approach 1: Create Separate Tables for
Superclass and Subclasses
– Each entity set (Employees, Hourly_Emps,
Contract_Emps) gets its own relation (table).
– The subclass tables include:
• Their own specific attributes.
• The primary key of the superclass (ssn) as both a primary key
and a foreign key.
Translating Class Hierarchies (ISA Hierarchies)
Translating Class Hierarchies (ISA Hierarchies)
▪ Advantages:
– Ensures proper referential integrity.
– Queries related to all employees can be answered using the Employees table.
– Queries related to specific subclasses are stored separately, avoiding unnecessary
joins.

▪ Disadvantages:
– Queries involving subclass-specific attributes (e.g., hourly_wages) require joins
with Employees.
– Cascade delete is required to remove subclass entries when an employee is deleted.
 Translating Class Hierarchies (ISA Hierarchies)
▪ Two Approaches to Mapping ISA Hierarchies to
Tables
– Approach 2: Merge Subclasses into Two Tables
(Flattening the Hierarchy)
– Instead of having a separate Employees table,
each subclass contains all employee attributes.
Translating Class Hierarchies (ISA Hierarchies)
 Translating Class Hierarchies (ISA Hierarchies)
▪ Advantages:
– Queries for specific subclass employees (e.g., hourly employees) are simpler and
do not require joins.
– Employees are directly classified into their roles without referring to a superclass
table.

▪ Disadvantages:
– Duplication of common attributes (name, lot) if an employee belongs to both
subclasses.
– If there are employees who do not belong to either subclass, they cannot be
stored.
 Translating ER Diagrams with Aggregation
▪ What is Aggregation in ER Diagrams?
– Aggregation is used when a relationship itself participates in
another relationship.

– It treats a relationship set as an entity, allowing it to form

connections with other entities.

▪ Understanding the Given ER Model

– Entities:
• Employees (ssn, name, lot)
• Projects (pid, pbudget, started_on)
• Departments (did, dname, budget)

– Relationships:
▪ Aggregation:
• Sponsors (pid, did, since) → Represents which department sponsors
which project.
– The Sponsors relationship is aggregated as it
• Monitors (ssn, pid, did, until) → Represents an employee monitoring a
sponsorship. participates in the Monitors relationship.
 Translating ER Diagrams with Aggregation
▪ Translating Aggregation to the Relational Model
– To map aggregation into relations, we create a table for
Monitors that includes:
• Primary key attributes of Employees (ssn).

• Primary key attributes of Sponsors (pid, did).

• Descriptive attributes of Monitors (until).

 Translating ER Diagrams with Aggregation
▪ Special Case: Dropping the Sponsors
Relation
▪ If the Sponsors relation:
– Has no descriptive attributes (like since).
– Has total participation in Monitors (every
sponsorship is monitored).

▪ Then, Sponsors can be omitted, since all its

information is already included in Monitors
(pid, did).
 ER to Relational: Additional Examples
▪ Understanding the ER Diagram
– The ER diagram involves:
• Employees (ssn, name, lot): The main
entity.
• Policies (policyid, cost, ssn): Policies
purchased by employees.
• Dependents (pname, age, policyid):
Dependents who are beneficiaries of a
policy.
– Key Relationships:
• An Employee (ssn) purchases a Policy.
• A Dependent (pname) is a Beneficiary of a
Policy.
 ER to Relational: Additional Examples

• Primary Key: policyid uniquely identifies a policy.

• Foreign Key: ssn ensures that each policy is associated with
an employee.
• ON DELETE CASCADE: If an employee is deleted, all their
policies are deleted.
 ER to Relational: Additional Examples
▪ Dependents Table (First Version)

• Primary Key: {pname, policyid} ensures uniqueness.

• Foreign Key: policyid references Policies to ensure that each
dependent is covered under a valid policy.
• ON DELETE CASCADE: If a policy is deleted, all related
dependents are removed.
 ER to Relational: Additional Examples
▪ Handling Weak Entities with Identifying
Relationships
– If policyid alone is not unique, then Policies should
be modeled as a weak entity.
– New Primary Key for Policies: {policyid, ssn} (policy is
unique only within an employee).
– Dependents table must change accordingly.

• Primary Key: {pname, policyid, ssn} ensures dependents are

unique within a policy and an employee.
• Foreign Key: {policyid, ssn} references Policies (because policyid
alone is not unique).
• ON DELETE CASCADE: If an employee's policy is deleted, all
associated dependents are also deleted.
▪ Find the minimum number of tables required to represent the given
ER diagram in relational model-
▪ Find the minimum number of tables required to represent the given
ER diagram in relational model-
▪ Find the minimum number of tables required to represent the given
ER diagram in relational model-
Unit-2
Part-2 By B. Lokesh Joel

131