1.

Difference between Database Schema and Database Instance

The database schema refers to the logical structure or blueprint of the
database. It defines the organization of data, including the tables, their
relationships, and the constraints that are imposed on the data. The schema is
typically fixed, describing how data is structured, and it does not change
frequently once it's defined.
The database instance, on the other hand, refers to the actual data stored in
the database at a specific point in time. It represents the content of the database
as it exists currently, including all the records or tuples in the tables defined by
the schema.
The database instance is more liable to change frequently because it involves
the actual data, which can be inserted, updated, or deleted by users or
applications as part of the normal operation. In contrast, the schema generally
remains stable unless there is a significant change in the requirements or
design of the database, which leads to schema modification.

2. Hierarchical, Relational, and Network Database Models

• Hierarchical Model: In this model, data is organized in a tree-like
structure, where each record has a single parent and possibly many
children. It uses parent-child relationships, making it efficient for certain
types of queries but inflexible for complex relationships. An example is an
organizational structure where each employee has one direct supervisor.
• Relational Model: The relational model organizes data into tables (also
called relations) consisting of rows (tuples) and columns (attributes). It
uses keys to establish relationships between tables, making it flexible and
easy to query. SQL is used to manipulate the data. This model is widely
used in modern databases, such as MySQL, PostgreSQL, and Oracle.
• Network Model: The network model is similar to the hierarchical model
but allows each record to have multiple parent records. It uses a graph
structure with nodes and connections (called sets) to represent complex
relationships. This model is more flexible than the hierarchical model but
still less intuitive than the relational model.

3. Relationship between Weak and Strong Entities

A strong entity is an entity that can exist independently and is uniquely
identifiable by its own attributes, typically through a primary key. For example,
a "Student" entity might be a strong entity, identified by a student ID.
A weak entity, in contrast, cannot exist without a strong entity. It is dependent
on a strong entity for its identification. A weak entity has a partial key, which is
combined with the key of the strong entity to form a unique identifier. An
example could be a "Dependent" entity in an employee database, which
depends on the "Employee" entity for identification.
The relationship between weak and strong entities is such that the weak entity
always relies on the strong entity to establish its identity.

4. Database Management System (DBMS) and its Advantages

A Database Management System (DBMS) is software that manages
databases and provides an interface for users and applications to interact with
the data. It handles data storage, retrieval, security, and integrity while
supporting operations like querying, updating, and deleting data.
Advantages of DBMS:
• Data Redundancy Control: A DBMS reduces data redundancy by
centralizing data storage.
• Data Integrity and Accuracy: A DBMS ensures that the data adheres to
predefined integrity constraints, thus maintaining its accuracy and
consistency.
• Security: A DBMS provides robust security features to control data
access and protect sensitive information.
• Concurrent Access: A DBMS allows multiple users to access and modify
the database simultaneously without conflicting changes.
• Backup and Recovery: DBMS ensures that data can be backed up and
recovered in case of failures.

5. Examples of Derived and Multivalued Attributes

• Derived Attributes: These are attributes whose values are derived from
other attributes. For example:
1. Age: Derived from the Date of Birth.
2. Total Salary: Derived from the Hourly Rate and Hours Worked.
• Multivalued Attributes: These are attributes that can hold multiple
values for a single entity. For example:
1. Phone Numbers: An employee can have multiple phone numbers.
2. Email Addresses: A person can have more than one email
address.

6. Functional Dependency and Types

A functional dependency (FD) is a relationship between two sets of attributes
in a relational database, where one attribute (or group of attributes) uniquely
determines another attribute (or group of attributes). In other words, if we know
the value of the determinant, we can determine the value of the dependent
attribute.
• Full Functional Dependency: A full functional dependency occurs when
an attribute is functionally dependent on the entire set of a composite key.
For example, in a table with the composite key (StudentID, CourseID),
the grade can depend fully on both attributes.
• Trivial Functional Dependency: A trivial functional dependency occurs
when an attribute is functionally dependent on a subset of itself or the
entire set. For example, (StudentID, Name) → Name is a trivial functional
dependency because the attribute (Name) depends on itself.

7. Role of a Database Administrator (DBA)

The Database Administrator (DBA) is responsible for overseeing the
management, maintenance, and operation of a database system. Their duties
include:
• Database Design: Ensuring the database structure supports business
requirements.
• Performance Tuning: Optimizing queries and ensuring the database
runs efficiently.
• Security Management: Setting up user roles and permissions to protect
data.
• Backup and Recovery: Implementing strategies for data backup and
restoration in case of data loss.
• Data Integrity: Ensuring the data remains accurate and consistent
through integrity constraints.

8. Data Abstraction in DBMS

Data abstraction is the process of hiding the complex details of the database
system and presenting only essential information to the users. It is achieved by
separating the database into different levels of abstraction, such as:
• Physical Level: Describes how data is stored in the database (e.g., file
systems).
• Logical Level: Describes what data is stored, and the relationships
among the data, but not how it is stored.
 • View Level: Defines what data a particular user can see, providing a
personalized view of the data.
Data abstraction allows for flexibility, as changes at one level (e.g., the physical
storage) do not affect the higher levels (e.g., the logical structure or views). It
simplifies database interactions for users and developers by shielding them
from the complexities of underlying systems.