1. What is DBMS?

Definition:

A Database Management System (DBMS) is a software application that enables users to create, manage, and
manipulate databases. It serves as an intermediary between users and the database, allowing for efficient data
management and retrieval.

Functions of DBMS:

• Data Storage, Retrieval, and Update: DBMS provides a structured way to store data in tables, allowing for
efficient retrieval using query languages like SQL (Structured Query Language).
• User Administration: DBMS allows for the creation of user accounts with specific permissions, ensuring that
users can only access data relevant to their roles.
• Data Integrity: DBMS enforces rules to maintain data accuracy and consistency. For example, it can prevent
duplicate entries and ensure that foreign keys match primary keys in related tables.
• Data Security: DBMS implements security measures such as encryption, user authentication, and access
controls to protect sensitive data.
• Backup and Recovery: DBMS provides tools for regular data backups and recovery options to restore data in
case of corruption or loss.
• Data Modeling: DBMS supports data modeling techniques, allowing designers to create visual representations
of data structures and relationships (e.g., ER diagrams).

Database Applications:

• Transaction Processing Systems: These systems handle a large number of transactions, such as banking
systems that process deposits and withdrawals.
• Customer Relationship Management (CRM): CRM systems manage customer interactions, sales data, and
marketing efforts (e.g., Salesforce, HubSpot).
• Enterprise Resource Planning (ERP): ERP systems integrate various business processes, such as finance, HR,
and supply chain management (e.g., SAP, Oracle ERP).
• Content Management Systems (CMS): CMS platforms manage digital content for websites, allowing users to
create, edit, and publish content (e.g., WordPress, Joomla).

Examples of DBMS:

• Relational DBMS: MySQL, PostgreSQL, Oracle Database, Microsoft SQL Server. These systems use tables to
represent data and relationships.
• NoSQL DBMS: MongoDB (document-oriented), Cassandra (wide-column store), Redis (key-value store). These
systems are designed for unstructured or semi-structured data.
• Object-oriented DBMS: db4o, ObjectDB. These systems store data in the form of objects, similar to object-
oriented programming.

People Behind Applications:

• Database Administrators (DBAs): Responsible for the installation, configuration, and maintenance of the
DBMS. They ensure data availability, performance, and security.
• Data Analysts: Analyze data to derive insights and support decision-making. They often use tools like SQL,
Python, or R for data analysis.
• Software Developers: Build applications that interact with the database, often using frameworks and libraries
that facilitate database connectivity.
• System Architects: Design the overall architecture of the database system, ensuring it meets business
requirements and scalability needs.
2. View of Data

Data View:

The view of data refers to how data is presented and accessed by users and applications. It can be categorized into
three levels:

1. Physical Level:

This level describes how data is physically stored in the database. It includes details about file structures,
indexing, and storage devices.

Example: Data may be stored in binary format on disk drives, with specific data structures like B-trees or hash tables
for indexing.

2. Logical Level(conceptual level):

This level represents the structure of the entire database as seen by the database administrator. It defines the
tables, relationships, and constraints without concern for how they are physically stored.

Example: A logical schema might define a "Students" table with attributes like "StudentID," "Name," and "Age," along
with relationships to other tables like "Courses."

3. View Level (or External Level) :

This level represents how individual users view the data. Different users may have different views based on their
roles and permissions.

Example: A student may see their grades and personal information, while an administrator may see all student records,
including sensitive data.
3. Seven Database Models with Diagrams and Examples

1. Hierarchical Model: The hierarchical model organizes data in a tree-like structure, where each record has a single
parent and potentially many children. This model is best suited for applications with a clear hierarchical relationship.

Diagram:

Example:

• Use Case: An organizational chart where a manager (Parent) has multiple employees (Children).
• DBMS Example: IBM Information Management System (IMS).

2. Network Model : The network model allows more complex relationships by enabling a record to have multiple
parents. It uses a graph structure to represent data, where entities can be connected in various ways.

Diagram:

Example:

• Use Case: A student can enroll in multiple courses, and each course can have multiple students.
• DBMS Example: Integrated Data Store (IDS).

3. Relational Model: The relational model organizes data into tables (relations) consisting of rows and columns. Each
table represents an entity, and relationships between tables are established through foreign keys.
Diagram:

Example:

• Use Case: A student can enroll in multiple courses, and each course can have multiple students.
• DBMS Example: MySQL, Oracle Database.

4. Object-oriented Model:The object-oriented model integrates object-oriented programming principles with

database technology. Data is represented as objects, which can contain both data and methods.

Diagram:

```

Example:

• Use Case: A student object can have attributes like name and age, and methods like enroll and drop.
• DBMS Example: ObjectDB, db4o.

5. Entity-Relationship Model (ER Model): The ER model is a high-level conceptual data model that defines data
elements and their relationships. It uses entities, attributes, and relationships to represent data.
Diagram:

Example:

• Use Case: A student enrolls in a course, establishing a relationship between the two entities.
• DBMS Example: Used in database design tools to create schemas.

6. Document Store Model : The document store model stores data in document formats, typically JSON or XML. Each
document is self-describing and can contain nested structures.

Diagram:

Example:

• Use Case: A student document can contain various attributes and nested arrays for courses.
• DBMS Example: MongoDB.

7. Key-Value Store Model : The key-value store model is a simple database model that uses a key to uniquely identify
a value. Each key is associated with a single value, which can be a simple data type or a more complex data structure.
Diagram:

Example:

• Use Case: Storing user profiles where each user ID is a key, and the associated value contains user details.
• DBMS Example: Redis, Amazon DynamoDB.

4. Three Schema Architecture

Users can view the schema level in a DB system using three-schema architecture or DBMS architecture. It contains 3
levels,

1. Internal level

2. Conceptual level

3. External or View level.

1.Internal Level: It contains an internal schema which describes the physical storage structure of the DB. Internal
schema uses “Physical data model” and describes the complete details of storage details and access path for the DB.

2. Conceptual Level: It describes the structure of the whole DB for a community/group of users. It hides the details of
physical storage structures and concentrates on describing the entities, data types, relationships, user operations and
constraints. It is implemented using “high-level data model”.
3. External or View Level: Contains several numbers of external schemas or user’s views. Each external schema
describes the part of the DB that a particular group is interested and hides the rest of the DB from that user group.
This level is implemented using a “representation data model”.

Mappings: The process of transforming request and results(responses) between various levels of DBMS architecture
is called as “MAPPINGS”. From the above DBMS architecture diagram, we can see two types of mappings,

1. External/Conceptual mapping

2. Conceptual/Internal Mappings

Data actually exists at the physical level or low-level schema. Each user refers to the external schema and requests
against the conceptual schema (External/Conceptual mapping) and then into a request on to the internal schema for
processing over the stored DB. (Conceptual/Internal mapping)

If the request is DB retrieval, the data extracted from the stored DB must be reformatted to match user’s external
view. This method of transforming requests and results between DBMS architecture levels is known as “MAPPINGS”.

5.define

a. Entity, Entity Sets, Entity Types:

• Entity: An entity is a real-world object or concept that can be distinctly identified. For example, a student or a
course.
• Entity Set: A collection of similar types of entities. For example, all students in a university form an entity set.
• Entity Type: Defines a category of entities that share common properties. For example, the entity type
"Student" may have attributes like "StudentID," "Name," and "Age."

b. Attributes and Its Types:

Attributes: Attributes are the properties or characteristics of an entity. For example, a "Student" entity may have
attributes like "Name," "Age," and "Email."

Types of Attributes:

• Simple Attribute: An attribute that cannot be divided further (e.g., "FirstName").

• Composite Attribute: An attribute that can be divided into smaller sub-parts (e.g., "FullName" can be divided
into "FirstName" and "LastName").
• Derived Attribute: An attribute whose value can be derived from other attributes (e.g., "Age" can be derived
from "DateOfBirth").
• Multi-valued Attribute: An attribute that can hold multiple values (e.g., "PhoneNumbers" can store multiple
phone numbers for a single student).

c. Relation and Its Types:

Relation: A relation is a set of tuples sharing the same attributes. In a relational database, a relation is represented as
a table.

Types of Relations:

• One-to-One (1:1): Each entity in set A is related to one and only one entity in set B (e.g., each student has one
student ID).
• One-to-Many (1:N): An entity in set A can be related to multiple entities in set B (e.g., a teacher can teach
multiple courses).
• Many-to-One (N:1): Multiple entities in set A can be related to a single entity in set B (e.g., many students can
belong to one department).
• Many-to-Many (M:N): Entities in set A can be related to multiple entities in set B and vice versa (e.g., students
can enroll in multiple courses, and each course can have multiple students).