Manipal University, Jaipur

School of information Technology

Department of Data Science and Engineering
Assignment-I
DS2201 Database Systems
DSE IV Semester Section A
Solution
Q.1 Discuss the main characteristics of the database approach and specify how it differs
from traditional file system.
Solution: The typical file-processing system is supported by a conventional operating system. The system
stores permanent records in various files, and it needs different application programs to extract records from,
and add records to, the appropriate files.
On the other hand, A database-management system (DBMS) is a collection of interrelated data and a set of
programs to access those data. The collection of data, usually referred to as the database, contains information
relevant to an enterprise.
The main characteristics of the database approach which differs it from traditional file system are,
➢ Data redundancy and inconsistency.
Data redundancy refers to the duplication of data within a database or across different databases or
files. When the same data is stored in multiple places, it increases storage requirements and can lead
to inefficiencies in data management.
Data inconsistency occurs when different copies of the same data do not match. Inconsistencies can
arise due to errors in data entry, lack of synchronization between different databases or systems, or
incomplete transactions.
➢ Difficulty in accessing data.
Suppose that one of the university clerks needs to find out the names of all students who live within a
particular postal-code area. The clerk asks the data-processing department to generate such a list.
Because the designers of the original system did not anticipate this request, there is no application
program on hand to meet it. There is, however, an application program to generate the list of all
students. The university clerk has now two choices: either obtain the list of all students and extract the
needed information manually or ask a programmer to write the necessary application program. Both
alternatives are obviously unsatisfactory. Suppose that such a program is written, and that, several days
later, the same clerk needs to trim that list to include only those students who have taken at least 60
credit hours. As expected, a program to generate such a list does not exist. Again, the clerk has the
preceding two options, neither of which is satisfactory. The point here is that conventional file-
processing environments do not allow needed data to be retrieved in a convenient and efficient manner.
 ➢ Data isolation.
Because data are scattered in various files, and files may be in different formats, writing new
application programs to retrieve the appropriate data is difficult.
➢ Integrity problems
The data values stored in the database must satisfy certain types of consistency constraints. Suppose
the university maintains an account for each department and records the balance amount in each
account. Suppose also that the university requires that the account balance of a department may never
fall below zero. Developers enforce these constraints in the system by adding appropriate code in the
various application programs. However, when new constraints are added, it is difficult to change the
programs to enforce them. The problem is compounded when constraints involve several data items
from different files.
➢ Atomicity problems
A computer system, like any other device, is subject to failure. In many applications, it is crucial that,
if a failure occurs, the data be restored to the consistent state that existed prior to the failure. it is
essential to database consistency that either both the credit and debit occur, or that neither occur. That
is, the funds transfer must be atomic—it must happen in its entirety or not at all. It is difficult to ensure
atomicity in a conventional file-processing system.
➢ Concurrent-access anomalies
It occurs when multiple users or processes attempt to access or modify the same data simultaneously.
These anomalies can lead to inconsistencies and errors in the data if proper concurrency control
mechanisms are not in place.
Q.2 What is the difference between logical data independence and physical data
independence? Which one is harder to achieve? Why?
Solution:
➢ Logical Data Independence: Logical data independence refers to the capacity to change the logical
structure of the database schema without changing the application programs that access the data. For
example, if you add a new table, modify an existing table, or change the relationships between tables
in the database, applications accessing the data should not need to be rewritten as long as they continue
to use the same logical model or data abstraction layer.
➢ Physical Data Independence: Physical data independence refers to the capacity to change the
physical storage structure of the database without affecting the logical schema or the application
programs that access the data. For example, if you change the storage mechanisms, indexing methods,
or file organization of the database, applications should not need to be modified, provided they interact
with the data through the logical schema.
Physical data independence is generally considered harder to achieve than logical data independence
because of following,
 Complexity of Physical Storage: Physical data independence involves managing the details of how data
is stored on disk, including file organization, indexing methods, storage allocation, and data compression.
These aspects can be highly complex and may vary significantly between different database management
systems and storage technologies.
Performance Considerations: Changes to the physical storage structure can have a significant impact on
database performance, requiring careful optimization and tuning to maintain acceptable levels of
performance. Achieving physical data independence while ensuring optimal performance can be
challenging and may require advanced techniques such as partitioning, clustering, and data distribution.
Dependency on Hardware and Operating System: Achieving physical data independence often requires
abstracting away dependencies on specific hardware configurations and operating system environments.
This requires additional layers of abstraction and may involve dealing with platform-specific optimizations
and constraints.
Data Migration and Compatibility: Changes to the physical storage structure may require migrating
existing data to the new storage format while ensuring data integrity and compatibility with existing
applications. This migration process can be complex and time-consuming, especially for large-scale
databases with extensive historical data.
Q.3 What is the difference between a candidate key and the primary key for a given relation in figure 3.1
, What is a super key?

Solution: A super key is a set of attributes within a relation that uniquely identifies each tuple. A super key
may contain additional attributes that are not strictly necessary for uniqueness.
A candidate key is a set of attributes within a relation (table) that uniquely identifies each tuple (row) in that
relation. It means that no two distinct tuples can have the same values for all the attributes in the candidate
key. A relation may have multiple candidate keys. Among the candidate keys, one is selected as the primary
key.
The primary key is one of the candidate keys chosen to uniquely identify each tuple in the relation. It is
designated as the main key for the relation and is used to enforce entity integrity. The primary key attribute(s)
must be unique and not null.

Q.4. Define domain, degree, and cardinality.?

Solution: In the context of relational databases and database management systems, the terms domain, degree,
and cardinality are fundamental concepts that help define the structure and characteristics of relations (tables).
1. Domain:
• The domain refers to the set of all possible values that an attribute (column) in a relation can
take.
• Each attribute in a relation is associated with a specific domain.
• Domains can be simple, such as integers, strings, dates, or complex, such as custom-defined
data types.
• Example: The domain of the "Age" attribute might be integers between 0 and 150.
2. Degree:
• The degree of a relation (table) is the number of attributes (columns) it contains.
• It represents the width or the number of fields in each tuple (row) of the relation.
• Degree is also referred to as arity.
• Example: If a relation has attributes (columns) for StudentID, Name, and Age, its degree is 3.
3. Cardinality:
• Cardinality refers to the number of tuples (rows) in a relation (table).
• It represents the height or the number of records in the relation.
• Cardinality can vary dynamically as data is inserted, updated, or deleted from the relation.
• Example: If a relation contains 100 tuples, its cardinality is 100.
Q.5 Discuss the mechanism of attribute relationship inheritance. How is it useful?
Solution: Attribute relationship inheritance is a mechanism in database design and object-oriented
programming that allows attributes and relationships defined in one entity or class to be inherited by another
entity or class. This concept is closely related to the principles of inheritance in object-oriented programming
languages.
Here's how attribute relationship inheritance works and why it's useful:
1. Inheritance Mechanism:
• Inheritance allows a subclass or derived entity to inherit attributes and relationships from a
superclass or base entity.
• The subclass automatically gains access to all the attributes and relationships defined in the
superclass, without the need to redefine them.
• The subclass can also add its own attributes and relationships or override existing ones
inherited from the superclass.
2. Usefulness:
a. Code Reusability: Attribute relationship inheritance promotes code reusability by allowing developers to
define common attributes and relationships once in a superclass and reuse them across multiple subclasses.
This reduces redundancy and promotes modular and maintainable code.
b. Consistency and Standardization: By centralizing the definition of attributes and relationships in a
superclass, attribute relationship inheritance ensures consistency and standardization across subclasses.
Changes made to the attributes or relationships in the superclass automatically propagate to all subclasses,
ensuring uniformity in data representation.
c. Simplifies Maintenance: Inheritance simplifies maintenance by providing a clear and hierarchical structure
to the data model. Developers can easily understand the relationships between entities and make changes to
the data model without affecting the entire system.
d. Facilitates Polymorphism: Inheritance facilitates polymorphism, allowing different subclasses to be
treated uniformly through the use of common interfaces or methods. This promotes flexibility and extensibility
in the system design, allowing new subclasses to be added without modifying existing code.
e. Improves Scalability: Attribute relationship inheritance supports scalability by allowing developers to
extend the data model with new subclasses as the requirements of the system evolve. This enables the system
to adapt to changing business needs and accommodate new features and functionalities.
Q.6 Illustrate about integrity and key constraints with suitable examples.?
Solution: Integrity and key constraints are crucial aspects of database design that ensure data consistency,
accuracy, and reliability. Let's illustrate these concepts with suitable examples:
1. Integrity Constraints:
Integrity constraints define rules that the data in a database must follow to maintain its integrity and validity.
There are several types of integrity constraints, including:
a. Entity Integrity Constraint:
• Entity integrity ensures that each row (tuple) in a table is uniquely identifiable by its primary
key and that it cannot contain null values in the primary key column(s).
• Example: In a "Students" table, the "StudentID" column might be defined as the primary key,
ensuring that each student has a unique identifier, and it cannot be null.
b. Referential Integrity Constraint:
• Referential integrity ensures the consistency and validity of relationships between tables by
enforcing foreign key constraints.
• Example: In a "Orders" table, the "CustomerID" column might be a foreign key referencing
the "Customers" table's primary key. The referential integrity constraint ensures that each order
must have a valid customer associated with it.
c. Domain Integrity Constraint:
• Domain integrity ensures that data values in a column conform to specific domain rules or data
types.
• Example: In a "Products" table, the "Price" column might have a domain integrity constraint
specifying that the price values must be numeric and non-negative.
2. Key Constraints:
Key constraints define the uniqueness and identification of rows within a table. There are several types of key
constraints, including:
a. Primary Key Constraint:
• A primary key constraint uniquely identifies each row in a table and ensures that the primary
key column(s) cannot contain duplicate or null values.
• Example: In an "Employees" table, the "EmployeeID" column might be defined as the primary
key, ensuring that each employee has a unique identifier.
b. Unique Constraint:
• A unique constraint ensures that the values in the specified column(s) are unique and cannot
contain duplicate values except for null values.
• Example: In a "Customers" table, the "Email" column might have a unique constraint, ensuring
that each customer's email address is unique across the table.
c. Foreign Key Constraint:
• A foreign key constraint establishes a relationship between two tables by referencing the
primary key or unique key of another table.
• Example: In an "Orders" table, the "CustomerID" column might be a foreign key referencing
the "Customers" table's primary key, establishing a relationship between orders and customers.
Q.7 Differentiate strong entity set and weak entity set. Demonstrate the concept of both
using real-time example using E-R diagram.
Solution: In the Entity-Relationship (E-R) model, strong entity sets and weak entity sets represent different
types of entities with distinct characteristics. Let's differentiate between them and provide examples using an
E-R diagram:
1. Strong Entity Set:
• A strong entity set is an entity set that has a primary key attribute, which uniquely identifies
each entity instance within the set.
• Instances of a strong entity set can exist independently of any other entity sets in the database.
• Strong entity sets are typically represented by rectangles in an E-R diagram.
Example: Consider an E-R diagram for a university database. The "Student" entity set can be considered a
strong entity set. Each student has a unique student ID, which serves as the primary key for the "Student"
entity set. Students can exist independently of any other entities in the database.
2. Weak Entity Set:
• A weak entity set is an entity set that does not have a primary key attribute capable of uniquely
identifying each entity instance on its own.
• Instances of a weak entity set depend on some related strong entity set, called the identifying
owner or parent entity set.
• Weak entity sets are typically represented by rectangles with double borders in an E-R diagram.
Example: Continuing with the university database example, consider the "Course Section" entity set. A course
section may not have a unique identifier on its own. Instead, it might depend on attributes like semester and
course ID, in addition to the unique identifier of its parent entity, the "Course" entity set. In this case, "Course"
is the identifying owner or parent entity set for "Course Section".
In the E-R diagram examples:
• The "Student" entity set is a strong entity set, as it has a primary key attribute (StudentID) capable of
uniquely identifying each student.
• The "Course Section" entity set is a weak entity set, as it depends on its parent entity, the "Course"
entity set, for its identification.

Q.8 Draw ER diagram for university database consisting of four entities Student,
Department, Class, and Faculty. Student has a unique id, the student can enrol for
multiple classes and has a most one major. Faculty must belong to department and
faculty can teach multiple classes. Each class is taught by only faculty. Every student will
get grade for the class he/she has enrolled.

Solution: Student entity has attributes like StudentID (primary key), Name, and MajorID (foreign key
referencing Major table).

Department entity has attributes like DeptID (primary key) and DeptName.

Class entity has attributes like ClassID (primary key), ClassName, DeptID (foreign key referencing
Department table), and FacultyID (foreign key referencing Faculty table).

Faculty entity has attributes like FacultyID (primary key), Name, and DeptID (foreign key referencing
Department table).

Enroll entity is a junction table representing the many-to-many relationship between Student and Class. It
contains attributes like StudentID (foreign key referencing Student table), ClassID (foreign key referencing
Class table), and Grade.

Draw a diagram as explained.

Q.9 Consider the BANK ER schema in Figure 7.21 and suppose that it is necessary to keep track of different
types of ACCOUNTS (SAVINGS_ACCTS, CHECKING_ACCTS, ...) and LOANS (CAR_LOANS,
HOME_LOANS, ...). Suppose that it is also desirable to keep track of each ACCOUNT’s TRANSACTIONS
(deposits, withdrawals, checks, ...) and each LOAN’s PAYMENTS; both include the amount, date, and time.
Modify the BANK schema, using ER and EER concepts of specialization and generalization. State any
assumptions you make about the additional.
Solution:
To modify the BANK schema to incorporate different types of accounts (e.g., savings accounts, checking
accounts) and loans (e.g., car loans, home loans), along with tracking transactions and payments, we can use
the concepts of specialization and generalization in the Enhanced Entity-Relationship (EER) model. Below is
the modified schema:
+------------+
| ENTITY |
+------------+
| EntityID |
+------------+
|
|
|
+-------------------------+
| ACCOUNT |
+-------------------------+
| AccountID |
| Balance |
| AccountType |
+-------------------------+
/ \
/ \
/ \
+---------------------------+ +-----------------------------+
| SAVINGS_ACCT | | CHECKING_ACCT |
+---------------------------+ +-----------------------------+
 | InterestRate | | OverdraftLimit |
+---------------------------+ +-----------------------------+
|
|
|
+------------------+
| TRANSACTION |
+------------------+
| TransactionID |
| Amount |
| Date |
| Time |
+------------------+
|
|
|
+------------------+
| LOAN |
+------------------+
| LoanID |
| Amount |
| LoanType |
+------------------+
|
|
|
+-------------------+
| PAYMENT |
+-------------------+
| PaymentID |
| Amount |
| Date |
| Time |
+-------------------+
Explanation:
• ENTITY: This represents the base entity for all entities in the schema. It includes common attributes
shared by all entities, such as EntityID.
 • ACCOUNT: This entity represents accounts in the bank. It includes attributes like AccountID
(primary key), Balance, and AccountType to differentiate between savings accounts, checking
accounts, etc.
• SAVINGS_ACCT and CHECKING_ACCT: These are specialization entities of the ACCOUNT
entity. They inherit attributes from the ACCOUNT entity and include additional attributes specific to
each account type.
• TRANSACTION: This entity tracks transactions related to accounts. It includes attributes like
TransactionID, Amount, Date, and Time.
• LOAN: This entity represents loans in the bank. It includes attributes like LoanID, Amount, and
LoanType to differentiate between car loans, home loans, etc.
• PAYMENT: This entity tracks payments related to loans. It includes attributes like PaymentID,
Amount, Date, and Time.
Assumptions:
• Each account has a unique AccountID.
• Each transaction and payment has a unique TransactionID and PaymentID, respectively.
• The AccountType attribute in the ACCOUNT entity differentiates between different types of accounts.
• The LoanType attribute in the LOAN entity differentiates between different types of loans.

Q.10 Consider the following relational database schema consisting of the four relation
schemas:

passenger ( pid, pname, pgender, pcity)

agency ( aid, aname, acity)

flight (fid, fdate, time, src, dest)

booking (pid, aid, fid, fdate)

Answer the following questions using relational algebra queries.

a. Get the details about all flights from Chennai to New Delhi.

σ src=Channai ∧ dest=New Delhi(flight)

b. Get the complete details of all flights to New Delhi.

πfid, fdate, time, src, dest(σ dest=New Delhi(flight))

c. Find the passenger names for passengers who have bookings on at least one flight.

πfid, fdate, time, src, dest(passenger ⨝ booking)

Q.11 Consider the relational database given below. Give an expression in the relational
algebra to express each of the following queries:

Employee (person-name, street, city),

Works (person-name, company-name, salary),

Company (company-name, city),

Manages (person-name, manager-name)

(1) Find name of all employees.

πperson-name(Employee)
(2) Find city of employee whose name is ‘jashu’.

πcity(σ person-name=jashu(Employee))
(3) Find name and city of all employees who are having salary>50000.

π person-name, city(σ salary> 50000(Employee⨝ Works))

(4) Find total salary of all employees who are working for company ‘HCL’.

Gsum(salary) (σ company-name= HCL(Works))

Q.12 Consider the following schema:

Suppliers (sid: integer, sname: string, address: string)

Parts (pid: integer, pname: string, color: string)

Catalog (sid: integer, pid: integer, cost: real)

The key fields are underlined, and the domain of each field is listed after the field name. Thus, sid is the key
for Suppliers, pid is the key for Parts, and sid and pid together form the key for Catalog. The Catalog relation
lists the prices charged for parts by Suppliers. Write the following queries in relational algebra.

1. Find the names of suppliers who supply some red part.

2. Find the sids of suppliers who supply some red or green part.

3. Find the sids of suppliers who supply some red part or are at 221 Packer Ave.

4. Find the sids of suppliers who supply some red part and some green part.

5. Find the sids of suppliers who supply every part.

6. Find the sids of suppliers who supply every red part.

7. Find the sids of suppliers who supply every red or green part.

8. Find the sids of suppliers who supply every red part or supply every green part.

9. Find pairs of sids such that the supplier with the first sid charges more for some part than the supplier with
the second sid.

10. Find the pids of parts that are supplied by at least two different suppliers.

11. Find the pids of the most expensive parts supplied by suppliers named Yosemite Sham.

12. Find the pids of parts supplied by every supplier at less than $200. (If any supplier either does not supply
the part or charges more than $200 for it, the part is not selected.

Solution: