Name- M Subhansu Patro

Redg no- 2301326135

Branch- B.tech (CSE)
Section- B
Subject- Database engineering

Group – A
Q1. How do schema and instances are related to a database?
Ans. In a database, schema and instances are two fundamental concepts that describe its
structure and content.

1. Schema (Structure)

 A schema is the overall design or blueprint of a database.

 It defines the structure of the database, including:
o Tables
o Columns (attributes)
o Data types
o Constraints (like primary keys, foreign keys)
o Relationships between tables
 The schema does not change frequently and provides a framework for storing and
organizing data.

Example: A schema for a university database might include:

CREATE TABLE Students (

StudentID INT PRIMARY KEY,
Name VARCHAR(100),
Age INT,
Major VARCHAR(50)
);

This schema defines what the students table should look like.

2. Instance (Data)

 An instance is the actual data stored in a database at a specific point in time.

 It represents a snapshot of the database's contents.
  Unlike the schema, which remains relatively stable, instances change frequently as
data is added, updated, or deleted.

Example: If we insert data into the student’s table:

INSERT INTO Students (StudentID, Name, Age, Major)

VALUES (1, 'Alice', 20, 'Computer Science');

Now, the table has an instance:

StudentID Name Age Major

1 Alice 20 Computer Science

This is one instance of the database. If another student is added, the instance changes.

Relationship Between Schema and Instance

 The schema defines the structure of the database.

 The instance represents the current state of the database.
 The schema is static (changes rarely), while the instance is dynamic (changes
frequently).
 A single schema can have multiple different instances over time.

Think of a schema as a Mold and instances as the different batches of items produced using
that Mold.

Q2. Explain data definition language (DDL) and data manipulation language
(DML).
Ans. Data Definition Language (DDL) vs. Data Manipulation Language
(DML)

Both DDL and DML are subsets of SQL (Structured Query Language) used for interacting
with databases, but they serve different purposes.

1. Data Definition Language (DDL)

DDL is used to define and modify the database structure, such as tables, schemas, and
indexes. These statements deal with metadata (data about data).

Key Characteristics of DDL:

 Defines the structure of the database.

 Includes commands for creating, altering, and deleting database objects.
  Changes made using DDL are permanent (auto-committed).
 Does not manipulate actual data.

Common DDL Commands:

Command Description
CREATE Creates a new table, database, index, or view.
ALTER Modifies an existing database object (e.g., adding a column).
DROP Deletes an entire table, database, or other objects.
TRUNCATE Removes all records from a table but keeps the structure.
RENAME Changes the name of an existing object.

Example of DDL:
CREATE TABLE Employees (
EmployeeID INT PRIMARY KEY,
Name VARCHAR(100),
Age INT,
Salary DECIMAL(10,2)
);

This command creates a table named Employees.

2. Data Manipulation Language (DML)

DML is used to retrieve, insert, update, and delete data in a database. It focuses on
handling the actual data inside tables.

Key Characteristics of DML:

 Deals with data manipulation (CRUD operations: Create, Read, Update, Delete).
 Changes made using DML can be rolled back (not auto-committed).
 Used for querying and modifying existing records.

Common DML Commands:

Command Description
SELECT Retrieves data from one or more tables.
INSERT Adds new records to a table.
UPDATE Modifies existing records in a table.
DELETE Removes specific records from a table.

Example of DML:
INSERT INTO Employees (EmployeeID, Name, Age, Salary)
VALUES (1, 'Alice', 30, 50000.00);
This command inserts a new employee record into the Employees table.

Key Differences Between DDL and DML

Feature DDL (Data Definition Language) DML (Data Manipulation Language)
Purpose Defines and modifies database structure. Manipulates actual data in tables.
Commands CREATE, ALTER, DROP, TRUNCATE SELECT, INSERT, UPDATE, DELETE
Effect Changes database schema (metadata). Changes table records (data).
Commit Auto-committed (permanent). Requires explicit commit/rollback.
Example CREATE TABLE Students (...) INSERT INTO Students (...)

Analogy:

 DDL is like designing a house (creating rooms, walls, and layout).

 DML is like arranging furniture (adding, modifying, or removing items inside the
house).

Q3. What is the extended ER model?

Ans. Extended ER Model (EER Model)

The Extended Entity-Relationship (EER) Model is an enhancement of the basic ER

(Entity-Relationship) Model, incorporating more advanced concepts to better represent
complex real-world data. It extends the ER model by adding features like specialization,
generalization, and aggregation.

Key Features of the EER Model

1. Specialization
o Definition: The process of creating subclasses from a general entity
(superclass).
o Use Case: Helps model hierarchical relationships where some entities have
additional attributes.
o Example:
 A "Person" entity can be specialized into "Student" and
"Professor", where:
 "Student" has attributes like StudentID, Major.
 "Professor" has attributes like EmployeeID, Department.
2. Generalization
o Definition: The reverse of specialization; multiple entities are merged into a
single higher-level entity.
o Use Case: Simplifies the model by reducing redundancy.
o Example:
  Entities "Car", "Truck", and "Motorcycle" can be generalized into
"Vehicle", which has common attributes like Model, Manufacturer.
3. Aggregation
o Definition: A higher-level abstraction where a relationship itself is treated as
an entity.
o Use Case: Useful when a relationship needs to participate in another
relationship.
o Example:
 Consider entities "Employee" and "Project" with a "Works_On"
relationship.
 If we want to track the "Manager" who oversees the "Works_On"
relationship, we can aggregate "Works_On" as an entity and link it to
"Manager."
4. Category (Union)
o Definition: A subclass (child entity) can have multiple superclasses (parent
entities).
o Use Case: Used when a single entity needs to inherit attributes from multiple
sources.
o Example:
 An entity "PartTimeProfessor" can be a subclass of both
"Professor" and "Employee", inheriting attributes from both.

Differences Between ER Model and EER Model

Feature ER Model Extended ER Model (EER)

Entities,
Includes all ER components plus Specialization,
Basic Components Relationships,
Generalization, Aggregation, and Category
Attributes
Hierarchy Supports inheritance (subclasses &
Not supported
Representation superclasses)
Complexity
Limited Can model more complex data structures
Handling
Advanced, real-world applications like banking,
Use Cases Simple databases
universities, healthcare

Example EER Diagram

If you're familiar with ER diagrams, an EER diagram looks similar but includes inheritance
(ISA relationships), aggregation, and generalization.

Person
/ \
Student Professor
(Has ID) (Has Salary)

This shows specialization, where "Person" is a superclass, and "Student" and "Professor"
are specialized subclasses.
Use Cases of the EER Model

 University Database (Students, Professors, Staff with inheritance)

 Banking System (Accounts categorized into Savings, Checking, etc.)
 E-Commerce (Users generalized into Customers, Sellers, and Admins)
 Hospital System (Doctors, Nurses, and Patients with specialization)

Q4. What are the key constrains and domain constrains in the relational
database?
Ans. Key Constraints and Domain Constraints in a Relational Database

In a relational database, constraints ensure data integrity and consistency. Two important
types of constraints are Key Constraints and Domain Constraints.

1. Key Constraints
Key constraints ensure that each row (tuple) in a table can be uniquely identified. They help
maintain uniqueness and entity integrity in a database.

Types of Key Constraints:

1. Primary Key Constraint

o A column (or set of columns) that uniquely identifies each row in a table.
o No two rows can have the same Primary Key value.
o Cannot have NULL values.
o Example:
o CREATE TABLE Students (
o StudentID INT PRIMARY KEY,
o Name VARCHAR(100),
o Age INT
o );

Here, StudentID is the Primary Key, ensuring each student has a unique ID.

2. Unique Key Constraint

o Ensures that all values in a column (or set of columns) are unique across the
table.
o Unlike Primary Key, it can have NULL values.
o Example:
o CREATE TABLE Employees (
o EmployeeID INT PRIMARY KEY,
o Email VARCHAR(100) UNIQUE
o );

Here, Email must be unique, but it can be NULL.

 3. Foreign Key Constraint
o Ensures referential integrity by enforcing a relationship between two tables.
o A column in one table refers to the Primary Key in another table.
o Example:
o CREATE TABLE Orders (
o OrderID INT PRIMARY KEY,
o CustomerID INT,
o FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
o );

Here, CustomerID in Orders table must exist in the Customers table.

4. Candidate Key
o A set of potential Primary Keys. Only one is chosen as the actual Primary
Key.
o Example:
 A Students table might have both StudentID and Email as unique
values. Both are Candidate Keys, but only one can be the Primary
Key.
5. Super Key
o A super set of a Candidate Key.
o It may contain extra attributes that are not necessary for uniqueness.
o Example: {StudentID, Email, Name} is a Super Key, but {StudentID}
alone is a Candidate Key.

2. Domain Constraints
Domain constraints ensure that a column's values belong to a specific range, data type, or
predefined set of values.

Types of Domain Constraints:

1. Data Type Constraint

o Ensures values are of a specific data type (INTEGER, VARCHAR, DATE,
etc.).
o Example:
o CREATE TABLE Employees (
o EmployeeID INT,
o Salary DECIMAL(10,2),
o JoinDate DATE
o );

Here, EmployeeID must be an integer, Salary must be a decimal, and

JoinDate must be a date.

2. Check Constraint
o Ensures values meet a specific condition.
o Example:
o CREATE TABLE Students (
 o StudentID INT PRIMARY KEY,
o Age INT CHECK (Age >= 18)
o );

Here, Age must be 18 or older.

3. Default Constraint
o Provides a default value when no value is provided.
o Example:
o CREATE TABLE Orders (
o OrderID INT PRIMARY KEY,
o Status VARCHAR(20) DEFAULT 'Pending'
o );

Here, if Status is not provided, it defaults to "Pending".

4. Not Null Constraint

o Ensures that a column cannot be NULL.
o Example:
o CREATE TABLE Employees (
o Name VARCHAR(100) NOT NULL,
o Email VARCHAR(100) NOT NULL
o );

Here, Name and Email cannot be left empty.

5. Enum Constraint (Predefined Set of Values)

o Restricts a column to specific values.
o Example (in MySQL):
o CREATE TABLE Employees (
o EmployeeID INT PRIMARY KEY,
o JobType ENUM('Full-Time', 'Part-Time', 'Contract') NOT NULL
o );

Here, JobType can only be 'Full-Time', 'Part-Time', or 'Contract'.

Summary Table:
Constraint Type Purpose
Primary Key Uniquely identifies each row. Cannot be NULL.
Unique Key Ensures column values are unique but can be NULL.
Foreign Key Maintains referential integrity between tables.
Candidate Key A set of attributes that can be a Primary Key.
Super Key A Candidate Key + extra attributes.
Data Type Constraint Ensures values match a specific data type (e.g., INT, VARCHAR).
Check Constraint Ensures values meet a condition (e.g., Age > 18).
Default Constraint Sets a default value when no value is provided.
Not Null Constraint Ensures a column cannot have NULL values.
Enum Constraint Restricts values to a predefined set.
Real-World Example

Imagine a Library Management System where:

 BookID is a Primary Key.

 ISBN is a Unique Key.
 MemberID in BorrowedBooks table is a Foreign Key referring to Members.
 Age in Members table has a Check Constraint (Age >= 12).
 Status in BorrowedBooks table has a Default Constraint ('Checked Out').
 DueDate must be NOT NULL.

These constraints ensure valid, consistent, and reliable data in the database.

Q5. What is the purpose of the renaming in a relational database?

Ans. Purpose of Renaming in a Relational Database

In a relational database, renaming is used to assign new names to tables, columns, or

attributes to improve readability, avoid conflicts, or simplify complex queries. It can be done
using the AS keyword in SQL (for temporary renaming) or the RENAME statement (for
permanent changes).

1. Reasons for Renaming in a Database

1. Improving Readability
o Shortening long table or column names for easier understanding.
o Example: Renaming EmployeeSalaryDetails to Salaries.
2. Avoiding Naming Conflicts
o When joining multiple tables with similar column names, renaming helps
avoid ambiguity.
o Example: If both Students and Teachers tables have a column Name,
renaming helps differentiate them.
3. Simplifying Complex Queries
o Assigning shorter aliases makes queries more readable, especially in joins and
subqueries.
4. Enhancing Data Presentation
o When generating reports or views, renaming columns provides user-friendly
output.
5. Modifying Database Structure
o Permanently renaming tables or columns when business requirements change.
2. Types of Renaming

(A) Temporary Renaming (Using ALIAS in SQL)

 Used within queries to temporarily rename tables or columns.

 The original names remain unchanged in the database.

Example 1: Renaming Columns with AS

SELECT EmployeeID AS ID, Name AS EmployeeName, Salary AS MonthlySalary

FROM Employees;

Here, EmployeeID, Name, and Salary are renamed only in the output.

Example 2: Renaming Tables in Queries

SELECT e.Name, d.DepartmentName

FROM Employees AS e
JOIN Departments AS d ON e.DepartmentID = d.DepartmentID;

Here, Employees is renamed as e, and Departments as d to simplify the query.

(B) Permanent Renaming (Using RENAME Statement)

 Used to permanently change the name of a table or column.

Example 1: Renaming a Table

RENAME TABLE OldEmployees TO Employees;

This permanently renames OldEmployees to Employees.

Example 2: Renaming a Column (MySQL, PostgreSQL)

ALTER TABLE Employees CHANGE COLUMN OldSalary Salary DECIMAL(10,2);

This renames OldSalary to Salary.

Example 3: Renaming a Column (SQL Server)

EXEC sp_rename 'Employees.OldSalary', 'Salary', 'COLUMN';

This permanently renames the OldSalary column.

3. Key Differences: Temporary vs. Permanent Renaming

 Feature Temporary Renaming (Alias) Permanent Renaming (RENAME)
Scope Only for the query Changes the actual database schema
Effect Affects only query results Affects the entire database
Usage For better readability in queries For structural changes in the database
Command AS keyword RENAME TABLE, ALTER TABLE

4. Real-World Use Case

Scenario:

A company wants to generate a report where:

 The Customer’s table is referenced multiple times.

 The OrderDate column needs to be displayed as PurchaseDate.

Solution (Using Aliases):

SELECT c1.CustomerID, c1.Name AS Buyer, c2.Name AS Referrer,

o.OrderDate AS PurchaseDate, o.TotalAmount
FROM Customers AS c1
LEFT JOIN Customers AS c2 ON c1.ReferredBy = c2.CustomerID
JOIN Orders AS o ON c1.CustomerID = o.CustomerID;

 Customers is aliased as c1 (Buyer) and c2 (Referrer).

 OrderDate is renamed as PurchaseDate for clarity.

Conclusion

Renaming is a powerful feature in relational databases that helps improve clarity, avoid
conflicts, and manage database structure changes. Whether temporary (using aliases) or
permanent (using RENAME or ALTER), it plays a vital role in making queries more readable and
databases more maintainable.

Q6. What is the division operator in a relational database?

Ans. Division Operator in a Relational Database

The division operator (÷) in relational algebra is used for queries that involve "for all"
conditions. It helps find entities that are related to all items in another set.

It is commonly used in many-to-many relationships, where we want to retrieve records that

are associated with every value in a related dataset.
1. Purpose of the Division Operator

The division operator is useful when answering questions like:

 "Find students who have enrolled in all available courses."

 "Find suppliers who supply all parts required for a project."
 "Find employees who have completed all required training modules."

It is used when:

1. There is a many-to-many relationship.

2. You need results that match every item in another dataset.

2. Syntax and Concept

Mathematical Representation:

If we have two relations:

 A (X, Y) → A relation that contains both X and Y attributes.

 B (Y) → A relation that contains only Y values that we need full coverage for.

The result of A ÷ B will be a new relation C (X), where:

 X contains only those values from A that have a corresponding entry for every value
in B.

Example Database Schema:

 StudentCourses(StudentID, CourseID) → (Students and the courses they are

enrolled in)
 AllCourses(CourseID) → (List of all courses that must be completed)

Query Objective:

Find students who have taken all courses listed in AllCourses.

Division Logic:

 Identify StudentIDs that appear with all CourseIDs in AllCourses.

 Return only those students.

3. Example of the Division Operator

Given Tables:
✅ StudentCourses (A)

StudentID CourseID
1 Math
1 Science
2 Math
2 Science
2 English
3 Math

✅ AllCourses (B)

CourseID
Math
Science

Expected Output:

Students who have taken all courses in AllCourses (Math and Science):

StudentID
1
2

4. SQL Equivalent of the Division Operator

SQL does not have a direct ÷ operator, but we can achieve the same effect using nested
queries.

SQL Query:

SELECT DISTINCT sc1.StudentID

FROM StudentCourses sc1
WHERE NOT EXISTS (
SELECT CourseID FROM AllCourses ac
WHERE NOT EXISTS (
SELECT * FROM StudentCourses sc2
WHERE sc2.StudentID = sc1.StudentID
AND sc2.CourseID = ac.CourseID
)
);

Explanation:

1. The inner NOT EXISTS query checks if there is any course in AllCourses that the
student has not taken.
2. The outer NOT EXISTS query ensures that only students who have taken every course
in AllCourses are selected.
3. DISTINCT ensures unique student IDs in the output.
5. Alternative SQL Approach Using GROUP BY and HAVING
SELECT StudentID
FROM StudentCourses
WHERE CourseID IN (SELECT CourseID FROM AllCourses)
GROUP BY StudentID
HAVING COUNT(DISTINCT CourseID) = (SELECT COUNT(*) FROM AllCourses);

Explanation:

1. Filters StudentCourses so that only courses present in AllCourses are considered.

2. Groups by StudentID and counts distinct courses.
3. Uses HAVING to ensure that the count matches the total number of required courses.

6. When to Use the Division Operator?

Scenario Use Division Operator?

Checking if an item exists in another table ❌ Use JOIN or EXISTS
Checking if an entity is related to all items in another
✅ Yes, use the division operator
table
Counting occurrences of relationships ❌ Use COUNT() with GROUP BY
Filtering records with partial matches ❌ Use INNER JOIN

7. Real-World Applications

 Student Enrollment: Find students who completed all required courses.

 Employee Training: Identify employees who passed all certification exams.
 Supplier Management: Find suppliers who provide all required parts.
 Retail Store Analysis: Identify customers who purchased all products in a specific
category.

8. Summary

Feature Description
Purpose Finds entities related to all values in another set
Used For Many-to-Many relationships
Example Students who completed all required courses
SQL Equivalent NOT EXISTS or HAVING COUNT(DISTINCT)
Real-World Uses Enrollment, Supplier-Parts, Employee Training
Group – B
Q1. How does a database management system (DBMS) differ from a file
management system?
Ans. Difference Between DBMS and File Management System

A Database Management System (DBMS) and a File Management System (FMS) are
both used for storing and managing data, but they differ significantly in terms of structure,
efficiency, security, and functionalities.

1. Key Differences: DBMS vs. File Management System

Database Management System
Feature File Management System (FMS)
(DBMS)
A software system that manages A system that stores and organizes
databases, allowing users to store, files in a hierarchical structure
Definition
retrieve, and manipulate data without enforcing relationships
efficiently. between data.
Stores data in tables (relations) with Stores data in files and folders with
Data Storage
a well-defined schema. no structured format.
Data Uses structured relationships between Each file is independent, with no
Organization tables. inherent relationships.
Data Eliminates redundancy through High redundancy due to repeated
Redundancy normalization and constraints. data in multiple files.
Ensures data consistency with No integrity checks—data
Data Integrity primary keys, foreign keys, and consistency must be managed
constraints. manually.
Uses SQL queries to retrieve and Requires manual searching or
Data Access
manipulate data. program-based access.
Offers authentication, access Limited security—relies on file
Security
control, and encryption. permissions.
Supports multiple users accessing Difficult to handle concurrent access;
Concurrency
data simultaneously. risk of conflicts.
Backup & Provides automatic backup and Requires manual backup; risk of data
Recovery recovery mechanisms. loss.
Optimized for fast querying, Slower searches; file-based retrieval
Performance
indexing, and searching. is less efficient.
Data Can handle large-scale data with
Struggles with large data volumes.
Scalability indexing and partitioning.
MySQL, PostgreSQL, Oracle DB, Windows File Explorer, Linux File
Examples
SQL Server System
2. Detailed Explanation
A) File Management System (FMS)

 A basic approach to storing data in files.

 Uses manual organization (folders, subfolders, text files, CSV, XML, etc.).
 No structured relationships between data.
 Common in legacy systems, personal storage, and small applications.

Example: Employee Data in FMS

Imagine an organization storing employee details in text files:

📁 employees.txt
📁 salaries.txt
📁 departments.txt

Each file independently holds data, requiring manual merging for retrieval.

B) Database Management System (DBMS)

 A centralized system for storing and managing structured data.

 Uses tables with defined relationships.
 Provides SQL-based queries for fast retrieval.
 Supports multi-user access, transactions, and security.

Example: Employee Data in DBMS

A relational database stores employee details in related tables:

✅ Employees Table

EmployeeID Name Age DepartmentID

101 Alice 30 D1
102 Bob 28 D2

✅ Departments Table

DepartmentID DepartmentName
D1 HR
D2 IT

To find all employees in HR, simply run:

SELECT Name FROM Employees WHERE DepartmentID = 'D1';

Unlike FMS, data is retrieved efficiently using queries.

3. Why Use DBMS Over FMS?
✅ Reduces Data Redundancy → One-time entry avoids duplication.
✅ Ensures Data Integrity → Foreign keys maintain data consistency.
✅ Allows Multi-User Access → Supports simultaneous data access.
✅ Provides Security → Role-based access control and encryption.
✅ Improves Efficiency → Query optimization speeds up searches.
✅ Supports Backup & Recovery → Automatic recovery in case of failure.

4. When to Use DBMS vs. File Management System?

Scenario Use DBMS? Use FMS?
Storing large structured data ✅ Yes ❌ No
Handling complex relationships ✅ Yes ❌ No
Single-user personal storage ❌ No ✅ Yes
Multi-user access required ✅ Yes ❌ No
High security needed ✅ Yes ❌ No
Fast searching and filtering ✅ Yes ❌ No
Storing small, temporary files ❌ No ✅ Yes

5. Conclusion
| FMS is useful for simple, personal, or small-scale storage but lacks security, integrity, and
efficiency.
| DBMS is the best choice for large, multi-user, and business-critical applications due to
data integrity, security, and performance.

Q2. What are keys in the relational model, and explain its different types?
Ans. Keys in a Relational Database

In a relational database, keys are used to identify records uniquely, enforce data
integrity, and establish relationships between tables.

1. What is a Key?
A key is an attribute (column) or a set of attributes that uniquely identifies a row (record)
in a table.
For example, in an employee’s table:

EmployeeID Name Department

101 Alice HR
102 Bob IT

 EmployeeID is a key because it uniquely identifies each employee.

2. Types of Keys in a Relational Database

(A) Primary Key

 A primary key (PK) uniquely identifies each record in a table.

 Must be unique and NOT NULL.
 Every table must have a primary key.

✅ Example (Students Table)

StudentID Name Age

1 John 20
2 Sarah 22

 StudentID is the Primary Key because it uniquely identifies each student.

✅ SQL Example:

CREATE TABLE Students (

StudentID INT PRIMARY KEY,
Name VARCHAR(50),
Age INT
);

(B) Candidate Key

 A candidate key is a column (or combination of columns) that can potentially be a

primary key.
 A table can have multiple candidate keys, but only one can be the primary key.

✅ Example (Employees Table)

EmployeeID Email Name

101 [email protected] Alice
102 [email protected] Bob

 EmployeeID and Email are candidate keys.

 Only one will be chosen as the Primary Key.
(C) Super Key

 A super key is any set of columns that uniquely identifies a row.

 It can contain extra columns beyond what is necessary.

✅ Example:

EmployeeID Email Name

101 [email protected] Alice
102 [email protected] Bob

 {EmployeeID} is a super key.

 {EmployeeID, Email} is also a super key (but contains extra data).

(D) Foreign Key

 A foreign key (FK) is a column that creates a relationship between two tables.
 It references a primary key from another table.
 Helps maintain referential integrity.

✅ Example (Orders Table referencing Customers Table)

Customers Table

CustomerID Name
1 John
2 Sarah

Orders Table

OrderID CustomerID Amount

5001 1 100
5002 2 200

 CustomerID in Orders is a Foreign Key referencing CustomerID in Customers.

✅ SQL Example:

CREATE TABLE Orders (

OrderID INT PRIMARY KEY,
CustomerID INT,
Amount DECIMAL(10,2),
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);
(E) Composite Key

 A composite key consists of two or more columns that together uniquely identify a
row.
 Used when a single column is not enough to ensure uniqueness.

✅ Example (Enrollment Table: One student can enroll in multiple courses)

StudentID CourseID Grade

1 101 A
1 102 B
2 101 A

 Neither StudentID nor CourseID alone can be a Primary Key.

 {StudentID, CourseID} together form a Composite Key.

✅ SQL Example:

CREATE TABLE Enrollment (

StudentID INT,
CourseID INT,
Grade CHAR(1),
PRIMARY KEY (StudentID, CourseID)
);

(F) Alternate Key

 An alternate key is any candidate key that was not chosen as the primary key.

✅ Example:
In the Employees Table, we had:

 EmployeeID (chosen as Primary Key)

 Email (Alternate Key)

✅ SQL Example:

ALTER TABLE Employees ADD CONSTRAINT unique_email UNIQUE (Email);

(G) Unique Key

 A unique key ensures that values in a column are unique, but NULL values are
allowed (unlike a Primary Key).

✅ Example (Vehicles Table)

VehicleID LicensePlate Model

1 ABC123 Tesla
VehicleID LicensePlate Model
2 XYZ789 Ford
3 NULL Honda

 LicensePlate must be unique but can have NULL values.

✅ SQL Example:

CREATE TABLE Vehicles (

VehicleID INT PRIMARY KEY,
LicensePlate VARCHAR(20) UNIQUE,
Model VARCHAR(50)
);

3. Summary Table
Key Type Definition Example
Uniquely identifies each row. Cannot
Primary Key EmployeeID in Employees table
be NULL.
Candidate A potential primary key (only one is
Email and EmployeeID
Key chosen).
Any column set that uniquely identifies {EmployeeID, Email}
Super Key
a row.
A key that references another table’s
Foreign Key CustomerID in Orders table
primary key.
Composite A primary key made of multiple {StudentID, CourseID} in
Key columns. Enrollment table
A candidate key not chosen as the
Alternate Key Email in Employees table
primary key.
Ensures unique values but allows
Unique Key LicensePlate in Vehicles table
NULL.

4. Conclusion
 Keys ensure data integrity, uniqueness, and relationships.
 Primary Keys uniquely identify records.
 Foreign Keys link related tables.
 Composite Keys handle complex cases.
 Unique Keys enforce uniqueness but allow NULL.

Q3. What is relational calculus? And how does it differ from the relational
algebra?
Ans. Relational Calculus vs. Relational Algebra in DBMS
1. What is Relational Calculus?

Relational Calculus is a non-procedural query language in a relational database

management system (RDBMS) that focuses on what to retrieve rather than how to
retrieve it.

 Uses mathematical logic (predicate logic) to define queries.

 Declarative: Specifies conditions that the desired data must satisfy.
 No explicit operations like joins or selections, just logical formulas.

2. Types of Relational Calculus

There are two types of Relational Calculus:

(A) Tuple Relational Calculus (TRC)

 Queries are written in the form of tuples (rows).

 Uses logical predicates to filter data.
 General form:
 { t | Condition(t) }

where it is a tuple and Condition(t) defines the required conditions.

✅ Example (Find students older than 20 years in the students table)

{ t | t ∈ Students ∧ t.Age > 20 }

This means: Select all tuples t from Students where t.Age > 20.

(B) Domain Relational Calculus (DRC)

Uses quantifiers (∃, ∀) and logical conditions.

 Queries are based on domain values (column values) instead of tuples.

 General form:
 { <x1, x2, ..., xn> | Condition(x1, x2, ..., xn) }

where x1, x2, ..., xn are domain variables.

✅ Example (Find names of students older than 20 years)

{ S.Name | ∃ Age (S ∈ Students ∧ S.Age > 20) }

This means: Select names of students where Age is greater than 20.
3. What is Relational Algebra?

Relational Algebra is a procedural query language that defines how to retrieve data from
relational databases.

 Uses a set of operators (like SELECT, PROJECT, JOIN, UNION).

 Step-by-step operations define data retrieval.
 More like SQL operations.

✅ Example (Find students older than 20 using Relational Algebra)

σ Age > 20 (Students)

This means: Select all records from Students where Age > 20.

4. Key Differences: Relational Calculus vs. Relational Algebra

Feature Relational Calculus Relational Algebra

Type Non-Procedural (Declarative) Procedural
Focus What data to retrieve How to retrieve data
Set operations (σ, π, ∪, ∩, ×,
Logical Predicates (∧, ∨, ¬, ∃, ∀)
Operators
Used ÷, JOIN)
Approach Uses mathematical logic Uses step-by-step operations
Requires understanding of algebraic
Readability Easier to understand (more like logic)
t ∈ Students ∧ t.Age > 20 }`
operations
Example `{ t
SQL Closer to Declarative SQL (e.g., Similar to procedural SQL (step-
Similarity SELECT statements) by-step queries)

5. Which One is Better?

Use Relational Calculus when 🚀 Use Relational Algebra when ⚡

You need logical, rule-based queries. You need step-by-step query execution.
You prefer a mathematical approach. You want explicit data retrieval operations.
You focus on "What data" You focus on "How to retrieve data"
(declarative). (procedural).

6. Summary

 Relational Calculus: Non-procedural, focuses on logic-based filtering.

 Relational Algebra: Procedural, focuses on step-by-step operations.
Both are foundations of SQL. SQL combines both concepts:

 SQL SELECT is closer to Relational Calculus.

 SQL operations like JOIN, GROUP BY follow Relational Algebra.

Would you like real-world SQL examples based on these concepts? 😊

Group – C
Q1. What are Codd’s rule?
Ans. Codd’s 12 Rules for Relational Databases

Dr. E.F. Codd, the father of relational databases, introduced 12 rules (actually 13,
including Rule 0) to define what qualifies as a true relational database management
system (RDBMS). These rules ensure data integrity, consistency, and flexibility.

Codd’s 12 Rules (Including Rule 0)

Rule
Rule Name Explanation
No.
A system must fully support relational principles to be
Rule 0 Foundation Rule
considered an RDBMS.
All data must be stored in tables (relations) as rows and
Rule 1 Information Rule
columns.
Every piece of data must be accessible using a unique
Rule 2 Guaranteed Access Rule
identifier (Primary Key).
Systematic Treatment of The system must allow NULL values to represent
Rule 3
NULL Values missing or unknown information.
A relational database must have a self-describing data
Rule 4 Dynamic Online Catalog
dictionary (metadata stored in tables).
Comprehensive Data The database must support a single language (like SQL)
Rule 5
Sub-language Rule for querying, defining, updating, and controlling data.
The system must allow updating views as if they were
Rule 6 View Updating Rule
real tables.
High-Level Insert, The system must allow operations on sets of data (bulk
Rule 7
Update, Delete operations) rather than one record at a time.
Physical Data Changes in storage structure should not affect the way
Rule 8
Independence data is accessed.
Logical Data Changes in table structure (schema modifications)
Rule 9
Independence should not affect applications using the database.
The system must support constraints (like Primary Key,
Rule
Integrity Independence Foreign Key, Unique, etc.) independently of
10
applications.
Rule Distribution A user should be able to access data without knowing
 Rule
Rule Name Explanation
No.
11 Independence where it is physically stored (distributed databases).
Rule If a system has a low-level language (e.g., procedural
Non-Subversion Rule
12 programming), it must not bypass relational rules.

Summary
 Codd’s Rules define what a true RDBMS must follow.
 Most modern databases like MySQL, PostgreSQL, and Oracle follow these
principles.
 SQL was designed based on these rules to ensure data consistency, security, and
flexibility.

Q2. What are the different types of joins in a relational algebra?

Ans. Types of Joins in Relational Algebra

Joins in Relational Algebra are used to combine data from two or more tables based on a
common attribute. They help retrieve related data efficiently.

1. Theta Join (θ-Join)

 A general join that combines tuples based on a condition (θ).
 Uses comparison operators (=, >, <, >=, <=, ≠).

✅ Notation:

R ⨝θ S

where θ is a condition.

✅ Example:
Find employees whose salary is greater than the salary of managers:

Employees ⨝ Employees.Salary > Managers.Salary Managers

2. Equi Join (≡-Join)

 A special case of Theta Join, where the condition uses only the "=" operator.
 It combines tuples with matching values in the common attribute.
✅ Notation:

R ⨝ A=B S

where A and B are attributes in R and S.

✅ Example:
Find employees and their department names:

Employees ⨝ Employees.DeptID = Departments.DeptID Departments

3. Natural Join (⋈)

 A special type of Equi Join, but automatically joins tables using common
attributes with the same name.
 No need to specify a condition explicitly.

✅ Notation:

R ⋈ S

✅ Example:

Employees ⋈ Departments

If both tables have a DeptID column, it automatically joins them on DeptID.

4. Outer Joins
Outer Joins preserve unmatched tuples from one or both tables by filling missing values
with NULL.

(A) Left Outer Join (⟕)

 Keeps all tuples from the left table.

 If there is no match in the right table, fills missing values with NULL.

✅ Notation:

R ⟕ S

✅ Example:

Employees ⟕ Departments

 Returns all employees and their departments.

  Employees without a department will have NULL for department details.

(B) Right Outer Join (⟖)

 Keeps all tuples from the right table.

 If there is no match in the left table, fills missing values with NULL.

✅ Notation:

R ⟖ S

✅ Example:

Employees ⟖ Departments

 Returns all departments, including those without employees (NULL values for
missing employees).

(C) Full Outer Join (⟗)

 Keeps all tuples from both tables.

 If there is no match, fills missing values with NULL.

✅ Notation:

R ⟗ S

✅ Example:

Employees ⟗ Departments

 Returns all employees and all departments, even if they don't match.

5. Semi Join (⋉ or ⋊)
 Only returns matching tuples from one table, but does not include columns from
the other table.
 Useful for filtering results.

✅ Left Semi Join (⋉) Notation:

R ⋉ S
✅ Right Semi Join (⋊) Notation:

R ⋊ S

✅ Example:
Find employees who belong to a department:

Employees ⋉ Departments

 Returns only employees who have a matching DeptID in Departments.

6. Anti Join (▷)

 Returns tuples from one table that do NOT have a match in the other.
 Opposite of Semi Join.

✅ Notation:

R ▷ S

✅ Example:
Find employees who do not belong to any department:

Employees ▷ Departments

 Returns employees whose DeptID is not found in Departments.

Summary Table: Types of Joins in Relational Algebra

Includes Unmatched
Join Type Description
Tuples?
Theta Join (⨝θ) Joins based on any condition (>, <, =) etc. ❌ No
Equi Join (⨝ A=B) Joins based only on equality condition (=) ❌ No
Natural Join (⋈) Automatically joins on common attributes ❌ No
Left Outer Join (⟕) Keeps all rows from the left table ✅ Yes (left)
Right Outer Join
Keeps all rows from the right table ✅ Yes (right)
(⟖)
Full Outer Join (⟗) Keeps all rows from both tables ✅ Yes (both)
Semi Join (⋉, ⋊)
Returns matching tuples from one table
❌ No
only
Returns tuples from one table that do NOT
Anti Join (▷) ✅ Yes (filtered records)
match
Conclusion
 Joins are crucial for combining related data in relational databases.
 Outer Joins help retain missing data, while Semi and Anti Joins help with filtering.
 SQL JOINs (INNER, LEFT, RIGHT, FULL, CROSS) are based on these
relational algebra operations.

Q3. Define relationship in DBMS and its different types with a proper diagram.
Ans. What is a Relationship in DBMS?

In DBMS (Database Management System), a relationship defines how two or more

entities are connected in a database. It represents real-world associations between tables.

For example, in a university database:

 A Student is related to a Course through enrollment.

 A Doctor is related to a Patient through treatment.

Types of Relationships in DBMS

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

 Each entity in Table A is related to only one entity in Table B.

 Rare in databases but used for secure or specific relationships.

✅ Example:

 Person → Passport (Each person has only one passport).

 CEO → Company (One company has one CEO).

✅ Diagram:

Person ────> Passport

(1) (1)

2. One-to-Many (1:M) Relationship

 One entity in Table A is related to many entities in Table B, but each entity in Table
B is linked to only one entity in Table A.

✅ Example:
  Teacher → Students (One teacher teaches multiple students, but each student has
only one teacher).
 Department → Employees (One department has multiple employees, but each
employee belongs to one department).

✅ Diagram:

Teacher ────< Students

(1) (M)

3. Many-to-Many (M:N) Relationship

 Multiple entities in Table A are related to multiple entities in Table B.

 Requires a junction table (bridge table) to resolve the relationship.

✅ Example:

 Students → Courses (A student can enroll in many courses, and each course can
have many students).
 Authors → Books (An author can write multiple books, and a book can have
multiple authors).

✅ Diagram:

Students ────< Enrollment >──── Courses

(M) (N)

Here, the Enrollment table helps connect Students and Courses.

4. Self-Referencing (Recursive) Relationship

 An entity is related to itself.

✅ Example:

 Employees → Manager (An employee reports to a manager, but the manager is also
an employee).
 Family Members → Parent-Child (A person can be both a child and a parent).

✅ Diagram:

Employee ────> Manager

(M) (1)

Here, the Employee table has a "Manager ID" referring to another employee.
Summary Table of Relationship Types in DBMS
Relationship
Description Example
Type
Each entity in Table A is linked to only one entity in Person →
One-to-One (1:1)
Table B. Passport
One-to-Many One entity in Table A is linked to multiple entities in Teacher →
(1:M) Table B. Students
Many-to-Many Multiple entities in Table A are linked to multiple Students →
(M:N) entities in Table B (needs a junction table). Courses
Employee →
Self-Referencing An entity relates to itself.
Manager

Conclusion

 Relationships help structure data logically in relational databases.

 One-to-Many (1:M) is the most commonly used relationship.
 Many-to-Many (M:N) requires an extra table for implementation