{ASSIGNMENT}

NAME VAIBHAV DAGADU HOLE

ROLL NUMBER 2314506392

PROGRAM BACHELOR OF COMPUTER APPLICATION

SEMISTAR III

COURSE NAME DATABASE MANAGEMENT SYSTEM

COURSE CODE DCA2102

(SET-1)

Q.NO.1. Ans: Cardinality is a fundamental concept in relational database design that governs
the relationships between entities or tables. It defines the maximum number of instances or
records in one entity that can be associated with instances or records in another entity.
Cardinality plays a vital role in maintaining data integrity, preventing redundancy, and enabling
efficient data retrieval and manipulation.

There are three primary types of cardinalities in relational database management systems
(RDBMS):

One-to-One (1:1) Cardinality: In this relationship type, a single record in the first entity can be
linked to at most one record in the second entity, and vice versa. This cardinality is relatively
uncommon and is typically employed when two entities share a significant overlap in data,
making it more efficient to separate them into distinct tables. For example, in a company
database, the "Employee" table could have a one-to-one relationship with the
"EmployeeContact" table, where each employee has a unique contact record.

One-to-Many (1:N) Cardinality: This cardinality indicates that a single record in the first entity
can be associated with multiple records in the second entity, but each record in the second entity
can only be linked to a single record in the first entity. A classic illustration of this relationship
is found in a university database, where the "Department" table has a one-to-many relationship
with the "Student" table, as each department can have multiple students enrolled, but each
student can only belong to one department.

Many-to-Many (N:M) Cardinality: In this relationship type, multiple records in the first entity
can be associated with multiple records in the second entity, and vice versa. To represent this
cardinality, a third table, known as a junction or bridge table, is introduced to store the mappings
between the two original entities. For example, in an e-commerce database, the "Product" table
and the "Order" table would have a many-to-many relationship, as a single order can contain
multiple products, and a single product can be included in multiple orders. A third table, such
as "OrderDetails," would be used to store the relationships between orders and products.

Proper implementation of cardinalities is crucial for maintaining data integrity and ensuring
efficient data management in relational databases. It helps prevent data redundancy, facilitates
the enforcement of referential integrity constraints, and enables accurate representation of real-
world relationships between entities. Understanding and correctly applying cardinalities is a
fundamental aspect of relational database design and implementation, as it ensures data
consistency and supports effective data retrieval and manipulation.

Q.NO.2. Ans: Entity Integrity and Referential Integrity are two fundamental principles that
govern data consistency and integrity within relational database management systems
(RDBMS). These constraints play a crucial role in maintaining the accuracy and reliability of
data stored in databases.

The Entity Integrity constraint mandates that the primary key column(s) of a table must not
contain null values, ensuring that each row or record within the table has a unique and non-null
primary key value. Primary keys serve as the unique identifiers for individual records, enabling
efficient data retrieval and manipulation. Violating this constraint can lead to ambiguity and
data inconsistencies, as records without unique identifiers cannot be reliably accessed or
updated.

On the other hand, the Referential Integrity constraint governs the relationships between tables.
It stipulates that the values in a foreign key column of one table must either match the
corresponding primary key values in the related table or be null. This constraint ensures that
any foreign key value present in a table refers to an existing primary key value in the associated
table. Failure to adhere to this constraint can result in orphaned or invalid data, compromising
the logical integrity of the database.

For example, consider a scenario involving two tables: "Department" and "Employee". The
"Employee" table contains a foreign key column "DepartmentID" that references the primary
key "DepartmentID" in the "Department" table. The referential integrity constraint ensures that
every value in the "DepartmentID" column of the "Employee" table corresponds to an existing
department ID in the "Department" table, or it must be null if an employee is not assigned to a
department.

Maintaining these integrity constraints is crucial for ensuring data consistency, preventing data
corruption, and supporting efficient data operations. The entity integrity constraint guarantees
the uniqueness and non-nullability of primary keys, enabling reliable record identification and
access. Simultaneously, the referential integrity constraint safeguards the logical relationships
between tables, preventing the introduction of invalid or orphaned data.

By enforcing these constraints, RDBMS systems contribute to the overall quality and reliability
of data stored within the database. Adherence to these principles facilitates robust database
applications, supports accurate data retrieval and manipulation, and enhances the overall
integrity and trustworthiness of the data stored in the database. Failure to uphold these
constraints can lead to data inconsistencies, errors, and potential data loss, undermining the
integrity and reliability of the database.

Q.NO.3. Ans: Transactions are fundamental building blocks in database management systems
(DBMS) that safeguard data integrity and consistency, especially when dealing with concurrent
access and potential system failures. A transaction is a logical unit of work comprising one or
more operations performed on a database. To maintain data integrity, a DBMS must ensure that
transactions adhere to four essential properties, commonly referred to as the ACID properties:
Atomicity, Consistency, Isolation, and Durability.

The Atomicity property ensures that a transaction is treated as an indivisible unit, where either
all operations within it are executed successfully, or none are executed at all. If any part of the
transaction fails, the entire transaction is rolled back, leaving the database in its previous
consistent state. This property guarantees that transactions are atomic and do not leave the
database in a partially updated state.

The Consistency property mandates that a transaction must transform the database from one
valid state to another, adhering to all defined rules, constraints, and integrity constraints. Before
and after the execution of a transaction, the database must remain in a consistent state,
satisfying all integrity constraints. If a transaction violates any constraints, it is aborted, and the
database reverts to its previous consistent state.

The Isolation property ensures that the intermediate state of a transaction is invisible to other
concurrent transactions. This property guarantees that multiple transactions running
concurrently do not interfere with each other, and each transaction appears to execute in
isolation, as if no other transactions were running simultaneously. Isolation is typically
achieved through concurrency control mechanisms such as locking or multi-version
concurrency control (MVCC).

The Durability property ensures that once a transaction is committed, its effects persist
permanently in the database, even in the event of system failures such as power outages or
crashes. Any changes made by a committed transaction are safely stored and cannot be lost or
undone due to failures. Durability is typically achieved through transaction logs and recovery
mechanisms.

By upholding these ACID properties, a DBMS can maintain data integrity and consistency,
even when dealing with concurrent access and system failures. Atomicity and consistency
ensure that transactions leave the database in a valid state, while isolation prevents concurrent
transactions from interfering with each other. Durability guarantees that committed transactions
are permanently stored and recoverable after system failures.

Adherence to these properties is crucial for mission-critical applications such as banking

systems, e-commerce platforms, and airline reservations, where data integrity and consistency
are paramount. Violating any of these properties can lead to data corruption, inconsistencies,
and potential financial or operational losses. Ensuring ACID compliance is thus a fundamental
requirement for any robust and reliable database management system, as it safeguards the
accuracy and reliability of data stored within the database.

(SET-2)

Q.NO.4. Ans:
Relational algebra is a procedural query language that consists of a set of operations used to
manipulate and retrieve data from relational databases. These operations allow various tasks to
be performed, such as selecting, filtering, combining, and transforming data from one or more
tables. Here are the different operations in relational algebra, along with examples to illustrate
their functionality:
Selection (σ):
The selection operation filters rows from a table based on a specified condition. For instance,
if a "Students" table is given and there is a need to select all students with a grade greater than
85, the selection operation can be used as follows:
𝜎𝑔𝑟𝑎𝑑𝑒 > 85(𝑆𝑡𝑢𝑑𝑒𝑛𝑡)
Projection (π):
The projection operation retrieves specific columns from a table. To select only the names and
grades of students from the "Students" table, the projection operation can be used as follows:
𝜋𝑛𝑎𝑚𝑒𝑠,𝑔𝑟𝑎𝑑𝑒(𝑆𝑡𝑢𝑑𝑒𝑛𝑡)
Union (∪):
The union operation combines the results of two or more queries into a single result set,
removing any duplicate rows. If two tables, "UndergraduateStudents" and "GraduateStudents,"
are available, they can be combined to get all students using:
(𝑈𝑛𝑑𝑒𝑟𝑔𝑟𝑎𝑑𝑢𝑎𝑡𝑒𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠) ∪ (𝐺𝑟𝑎𝑑𝑢𝑎𝑡𝑒𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠)
Difference (−):
The difference operation returns the rows from one relation that are not present in another. To
find students who are only in the "UndergraduateStudents" table and not in the
"GraduateStudents" table, the difference operation can be used as follows:
(𝑈𝑑𝑒𝑟𝑔𝑟𝑎𝑑𝑢𝑎𝑡𝑒𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠 − 𝐺𝑟𝑎𝑑𝑢𝑎𝑡𝑒𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠)

Cartesian Product (×):

The Cartesian product operation combines every tuple of one relation with every tuple of
another relation. If a "Courses" table and an "Instructors" table are available, they can be
combined to get all possible instructor-course pairs using:
(𝐶𝑜𝑢𝑟𝑠𝑒𝑠 × 𝐼𝑛𝑠𝑡𝑟𝑢𝑐𝑡𝑜𝑟𝑠)
Rename (ρ):
The rename operation is used to change the name of a table or column in a query result. For
example, to rename the “Students” table to “EnrolledStudents,” the rename operation can be
used as follows:
𝜌𝐸𝑛𝑟𝑜𝑙𝑙𝑒𝑑𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠(𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠)
Natural Join (⋈):
The natural join operation combines tuples from two relations based on common attributes. If
a "Students" table and an "Enrollments" table are available, they can be joined based on a
common attribute like "student_id" using:
𝑆𝑡𝑢𝑑𝑒𝑛𝑡𝑠 ⋈ (𝑠𝑡𝑢𝑑𝑒𝑛𝑡, 𝑑)𝐸𝑛𝑟𝑜𝑙𝑙𝑚𝑒𝑛𝑡𝑠

Division (÷):
The division operation is used to find tuples in one relation that match all tuples in another
relation. If a "Students" table and a "Courses" table are available, and there is a need to find
students enrolled in all courses, the division operation would be used.
These operations in relational algebra provide a powerful and flexible way to manipulate and
query data in relational databases. They form the foundation for more advanced query
languages, such as SQL, and are essential for understanding and optimizing database queries.

Q.NO.5. Ans:
Normalization is a database design technique aimed at minimizing redundancy and dependency
by organizing fields and table structures. The goal is to divide a database into well-structured
tables to ensure data integrity and reduce anomalies during data operations like insertion,
updating, or deletion. There are different normal forms that databases can adhere to, each with
its own set of rules and guidelines:
First Normal Form (1NF):This form ensures that each column contains atomic (indivisible)
values and that each entry in a column is of the same data type. For example, a table of students
with subjects might initially store multiple subjects in a single column. To achieve 1NF, you
would separate these into individual rows.
This form ensures that each column contains atomic (indivisible) values and that each entry in
a column is of the same data type. For example, a table of students with subjects might initially
store multiple subjects in a single column. To achieve 1NF, you would separate these into
individual rows.
Example:
Student_ID Name Subjects
1 Aarav Math, Physics
2 Priya Chemistry, Biology
In 1NF, we split the subjects into separate rows:
Student_ID Name Subject
1 Aarav Math
1 Aarav Physics
2 Priya Chemistry
2 Priya Biology
Second Normal Form (2NF):
A table is in 2NF when it is in 1NF, and all non-key attributes are fully functionally dependent
on the primary key. Consider a table with composite primary keys, where initially, the non-key
attributes are not fully dependent on the primary key. To achieve 2NF, you would separate these
attributes into their own table.
Example:
Student_ID Course_ID Instructor Instructor_Phone
1 C1 Dr. Sharma 987-654-3210
1 C2 Dr. Patel 876-543-2109
2 C1 Dr. Sharma 987-654-3210
In 2NF, the Instructor_Phone depends on the Instructor, not the composite primary key. So, we
separate the table into two:
Table 1:
Student_ID Course_ID Instructor
1 C1 Dr. Sharma
1 C2 Dr. Patel
2 C1 Dr. Sharma
Table 2:
Instructor Instructor_Phone
Dr. Sharma 987-654-3210
Dr. Patel 876-543-2109
Third Normal Form (3NF):
This form ensures that the table is in 2NF, and all non-key attributes are not transitively
dependent on the primary key. For instance, if a table has a transitive dependency, where a non-
key attribute is dependent on another non-key attribute, you would separate these attributes
into their own table to achieve 3NF.
Example:
Student_ID Name Department Department_Location
1 Aarav Computer Science Block A
2 Priya Physics Block B
In 3NF, the Department_Location depends on the Department, not directly on the Student_ID.
So, we separate this into a new table:
Table 1:
Student_ID Name Department
1 Aarav Computer Science
2 Priya Physics
Table 2:
Department Department_Location
Computer Science Block A
Physics Block B
Boyce-Codd Normal Form (BCNF):
BCNF is a stricter version of 3NF, where every determinant is a candidate key. If a table has
more than one candidate key and some dependencies violate 3NF, you would need to separate
these attributes into their own tables to achieve BCNF.
Example:
Student_ID Course_ID Instructor Instructor_Phone
1 C1 Dr. Sharma 987-654-3210
1 C2 Dr. Patel 876-543-2109
2 C1 Dr. Sharma 987-654-3210
In this case, Instructor determines Instructor_Phone, but Instructor is not a candidate key. So,
we split the table into two:
Table 1:
Student_ID Course_ID Instructor
1 C1 Dr. Sharma
1 C2 Dr. Patel
2 C1 Dr. Sharma
Table 2:
Instructor Instructor_Phone
Dr. Sharma 987-654-3210
Dr. Patel 876-543-2109

By ensuring that a database is designed according to these normal forms, it becomes more
efficient and less prone to anomalies, resulting in a more robust and reliable system.
Normalization helps to eliminate redundant data, reduce the risk of data inconsistencies, and
improve data integrity overall. It's important to note that while normalization is a crucial aspect
of database design, it's also essential to strike a balance between normalization and
performance. In some cases, denormalization techniques may be employed to improve query
performance, but this should be done judiciously and with a clear understanding of the trade-
offs involved.

Q.NO.6. Ans:
Fragmentation in database systems refers to splitting a database into smaller pieces, called
fragments, to enhance performance, manageability, and availability. This technique is
especially beneficial in distributed databases, where data is spread across multiple locations or
sites.
Types of Fragmentation
Horizontal Fragmentation: Horizontal fragmentation involves dividing a table into subsets of
rows (tuples) based on a specific condition. Each fragment contains a subset of the rows. For
instance, consider a "Customer" table with columns such as CustomerID, Name, City, and
Country. Horizontal fragmentation could divide this table into two fragments, one for
customers residing in India and another for customers outside India.
India_Customers:
CustomerID Name City Country
1 Rahul Mumbai India
2 Priya Bangalore India

NonIndia_Customers:
CustomerID Name City Country
3 Michael New York USA
4 Sophie Paris France

Vertical Fragmentation: Vertical fragmentation divides a table into subsets of columns

(attributes). Each fragment contains a subset of the columns. Using the same "Customer" table
example, vertical fragmentation might split the table into two fragments: one containing
customer personal details (CustomerID, Name) and another containing customer location
details (CustomerID, City, Country).
PersonalDetails:
CustomerID Name
1 Rahul
2 Priya
3 Michael
4 Sophie

LocationDetails:
CustomerID City Country
1 Mumbai India
2 Bangalore India
3 New York USA
4 Paris France
Hybrid (or Mixed) Fragmentation is a combination of both horizontal and vertical
fragmentation techniques. In this approach, a table is first horizontally fragmented, and then
each resulting fragment is further vertically fragmented, or vice versa. For instance, consider a
"Customer" table in a database. A hybrid fragmentation approach might first divide the table
horizontally by country, and then each resulting fragment could be vertically split into separate
fragments containing personal details and location details.
Fragmentation offers several advantages in database management systems:

Improved Performance: By storing only relevant fragments at specific locations, queries can
be processed faster as they only need to access the required data, reducing the amount of data
that needs to be transferred or processed.

Increased Availability: If one fragment becomes unavailable due to system failures or

maintenance, other parts of the database can still be accessed, ensuring higher availability and
continuity of operations.

Enhanced Security: Sensitive data can be isolated in specific fragments, providing better
control over access and data security by restricting access to only the necessary fragments.
However, fragmentation also presents some disadvantages:

Complexity: Managing and maintaining a fragmented database is more complex than a non-
fragmented one, requiring additional coordination and synchronization efforts to ensure data
consistency across fragments.

Data Integrity: Ensuring data integrity and consistency across multiple fragments necessitates
careful management and synchronization mechanisms to prevent data inconsistencies or
anomalies.

Despite these challenges, fragmentation remains a valuable technique in database management,

particularly in distributed environments, as it optimizes performance and management by
allowing data to be stored closer to where it is needed and reducing the amount of data that
needs to be transferred or processed. However, the decision to fragment a database should be
carefully evaluated, considering factors such as data access patterns, performance
requirements, and the complexity of managing fragmented data.