💻

Unit 1: Introduction to Database

1.1 Introduction to Databases and Database Technology

1. Definition of a Database
Database: A collection of related data with implicit meaning, recordable
facts.

Examples: Names, phone numbers, addresses in mobile phones,

indexed address books, or stored on PCs using software like Microsoft
Access or Excel.

2. Properties of a Database
Represents Real World: Reflects changes in the miniworld (universe of
discourse).

Logically Coherent: Organized collection with inherent meaning, not

random data.

Purposeful Design: Built for specific purposes, with intended users and
applications.

Dynamic Interaction: Changes in the real world should be promptly

reflected in the database.

3. Types and Sizes of Databases

Unit 1: Introduction to Database 1

 Simple: Small, few hundred records with simple structure (e.g., personal
address book).

Complex: Large, such as a library catalog or social media database, with

sophisticated organization and massive data (e.g., Facebook).

Commercial: Large-scale, such as Amazon.com’s database with millions of

users and items, continuously updated.

4. Database Creation and Maintenance

Manual vs. Computerized: Can be created/maintained manually (e.g.,
library card catalog) or computerized (via application programs or DBMS).

DBMS (Database Management System): Software system enabling

database creation, maintenance, and interaction.

5. Functions of DBMS
Defining: Specify data types, structures, and constraints; stored as meta-
data in a database catalog/dictionary.

Constructing: Store data on controlled storage medium.

Manipulating: Querying, updating, and report generation.

Sharing: Allowing multiple users and applications simultaneous access.

Protecting: System protection (hardware/software failures) and security

against unauthorized access.

Maintaining: Adapting to changing requirements over time.

6. Database System
Components: Comprises both the database and the DBMS software.

7. Custom vs. General-Purpose DBMS

General-Purpose DBMS: Versatile, widely used for various applications.

Custom Programs: Specific applications may use customized software,

requiring complex programming efforts (e.g., airline reservations).

This overview highlights the importance, structure, and functionalities of

databases and database management systems, illustrating their critical role in

Unit 1: Introduction to Database 2

 various fields and the complexities involved in their development and
maintenance.

1.2 An Example

In this example, we consider a UNIVERSITY database designed to manage

information about students, courses, grades, and prerequisites. The database
is organized into five files, each storing records of the same type:

1. STUDENT file: Stores data on each student, including their Name,

Student_number, Class, and Major.

2. COURSE file: Contains information about each course, such as

Course_name, Course_number, Credit_hours, and Department.

3. SECTION file: Records data about each course section, including

Section_identifier, Course_number, Semester, Year, and Instructor.

4. GRADE_REPORT file: Documents the grades students receive in various

sections, including Student_number, Section_identifier, and Grade.

Unit 1: Introduction to Database 3

 5. PREREQUISITE file: Lists the prerequisites for each course, containing
Course_number and Prerequisite_number.

Each record type has a specific structure. For example, a STUDENT record
might include:

Name: A string of alphabetic characters.

Student_number: An integer.

Class: A coded integer (e.g., 1 for freshman, 2 for sophomore).

Major: A string (e.g., ‘CS’ for Computer Science).

The relationships between records are crucial. For example, a STUDENT record
for Smith relates to multiple GRADE_REPORT records specifying Smith's grades
in different sections. Similarly, PREREQUISITE records link course records by
specifying required prerequisites.

Examples of database queries:

Retrieve Smith's transcript, listing all courses and grades.

List names of students and their grades for the 'Database' course section in
Fall 2008.

List the prerequisites for the 'Database' course.

Examples of updates:

Change Smith's class to sophomore.

Create a new section for the 'Database' course this semester.

Enter a grade of 'A' for Smith in the 'Database' section from last semester.

The database is part of a broader information system within an organization,

typically managed by the IT department. The design process involves several
stages:

1. Requirements Specification and Analysis: Documenting detailed

requirements.

2. Conceptual Design: Representing the database using tools like the Entity-
Relationship (ER) model.

3. Logical Design: Translating the conceptual design into a data model

supported by a commercial DBMS.

4. Physical Design: Providing specifications for storage and access methods.

Unit 1: Introduction to Database 4

 Once designed, the database is implemented, populated with data, and
maintained to accurately reflect the real-world system it models.

1.3 Characteristics of the database approach

The characteristics of the database approach set it apart from traditional file
processing methods, where each user defines and manages their own files and
programs. Let's break down these characteristics:

1. Self-Describing Nature of a Database System

Unit 1: Introduction to Database 5

 In a database system, the structure and constraints of the database are
fully described in a catalog within the DBMS.

This catalog, containing metadata, includes details such as file structure,

data types, and constraints.

Unlike traditional file processing where data definitions are part of

application programs, the database approach separates data definition
from application programming.

The catalog allows DBMS software to work with any database application
by referencing the database structure stored within it.

2. Insulation between Programs and Data, and Data Abstraction

Database systems provide insulation between programs and data, known
as program-data independence.

Changes to the structure of data files do not necessarily require changes to

access programs.

Data abstraction hides storage and implementation details from users,

focusing on conceptual representations of data.

Operations on data can be defined independently of their implementation,

facilitating program-operation independence.

3. Support of Multiple Views of the Data

A database system accommodates diverse user perspectives by allowing
the definition of multiple views.

Views may represent subsets of the database or virtual data derived from it.

Users can access customized views tailored to their specific needs without
needing to understand the underlying database structure.

4. Sharing of Data and Multiuser Transaction Processing

Multiuser DBMS enables simultaneous access to the database by multiple
users.

Concurrency control mechanisms ensure that concurrent updates to the

database occur in a controlled manner to maintain data consistency.

Transactions, which consist of one or more database operations, ensure

data integrity and enforce properties like isolation and atomicity.

Unit 1: Introduction to Database 6

 These characteristics collectively distinguish the database approach from
traditional file processing methods, offering advantages in data management,
flexibility, and user accessibility.

1.4 Actors on the Scene

In managing a large database within an organization, various individuals play
critical roles. Let's explore the key actors involved in the day-to-day use and
maintenance of a large database:

1. Database Administrators (DBAs)

Responsibility: Overseeing and managing database resources and the
DBMS.

Tasks:

Authorizing access to the database.

Coordinating and monitoring database usage.

Acquiring necessary software and hardware resources.

Assistance: In larger organizations, DBAs may lead a team to fulfill these

responsibilities effectively.

2. Database Designers
Responsibility: Designing the database structure and choosing appropriate
data storage structures.

Tasks:

Identifying data to be stored and understanding user requirements.

Communicating with prospective users to ensure the design meets their

needs.

Developing views of the database for different user groups and

integrating them into a cohesive design.

Transition: After completing the database design, designers may take on

other responsibilities within the organization.

3. End Users

Unit 1: Introduction to Database 7

 Role: Individuals whose job functions require regular access to the
database.

Categories:

Casual End Users: Occasionally access the database for varying

information needs.

Naive or Parametric End Users: Regularly query and update the

database using standard transactions or mobile apps tailored for
specific tasks.

Sophisticated End Users: Engineers, scientists, analysts, etc., who

utilize the full capabilities of the DBMS to meet complex requirements.

Standalone Users: Maintain personal databases using user-friendly

software packages.

Learning Curve: End users' proficiency with the database depends on the
complexity of their tasks and the user interface provided.

4. System Analysts and Application Programmers (Software

Engineers)
Responsibility: Analyzing end user requirements and developing
specifications for standard transactions.

Tasks:

Determining end user requirements, especially for naive and parametric

users.

Developing specifications for standard transactions.

Implementing, testing, debugging, documenting, and maintaining these

transactions.

Expertise: Analysts and programmers need to be well-versed in the

capabilities of the DBMS to fulfill their tasks effectively.

Each of these actors plays a crucial role in ensuring the effective management,
utilization, and maintenance of the database within the organization.

1.5 Workers behind the Scenes

Behind the scenes of a database system, several individuals work on the
design, development, and maintenance of the DBMS software and system

Unit 1: Introduction to Database 8

 environment. These individuals are crucial for ensuring the smooth operation of
the database system, even though they are not directly involved in using the
database contents. Let's explore these categories:

1. DBMS System Designers and Implementers

Role: Designing and implementing the various modules and interfaces of
the DBMS software.

Tasks:

Designing modules for catalog management, query processing,

interface handling, data access and buffering, concurrency control,
data recovery, and security.

Implementing these modules as a cohesive software package.

Complexity: Building a DBMS involves handling a wide array of system

components and interfacing with other system software like operating
systems and compilers.

2. Tool Developers
Role: Designing and developing software tools that aid in database
modeling, system design, and performance enhancement.

Tasks:

Creating tools for database design, performance monitoring, natural

language or graphical interfaces, prototyping, simulation, and test data
generation.

These tools are often separate packages purchased by organizations to

complement their DBMS.

Independence: Tool development may be undertaken by independent

software vendors who market these tools separately.

3. Operators and Maintenance Personnel (System

Administration)
Role: Responsible for the day-to-day operation and maintenance of the
hardware and software environment hosting the database system.

Tasks:

Ensuring the smooth running of hardware components.

Unit 1: Introduction to Database 9

 Installing, configuring, and updating software components.

Monitoring system performance and addressing any issues promptly.

Criticality: Operators and maintenance personnel play a vital role in

ensuring the availability and reliability of the database system.

While these individuals work behind the scenes and are not directly involved in
utilizing the database contents for their own purposes, their contributions are
indispensable for the efficient functioning of the database system.

1.6 Advantages of Using the DBMS Approach

The advantages of using the database management system (DBMS) approach
extend beyond the core characteristics discussed earlier. Let's explore these
additional advantages:

1. Controlling Redundancy
Issue: Traditional file processing systems lead to redundant storage of data
across different user groups.

DBMS Solution: Integrated database design minimizes redundancy through

data normalization, ensuring consistency and saving storage space.

Controlled Redundancy: In some cases, controlled redundancy

(denormalization) may improve query performance, but the DBMS should
enforce consistency checks to prevent inconsistencies.

2. Restricting Unauthorized Access

Challenge: Large databases often contain confidential information that only
authorized users should access.

DBMS Solution: Provides a security and authorization subsystem to control

access based on user roles and permissions.

Automatic Enforcement: The DBMS automatically enforces access

restrictions specified by the DBA, ensuring data security.

3. Providing Persistent Storage for Program Objects

Benefit: Databases can store program objects and data structures
persistently, surviving program terminations.

Unit 1: Introduction to Database 10

 Object-Oriented Support: Object-oriented database systems offer
compatibility with programming languages like C++ and Java, automatically
handling conversions.

4. Providing Storage Structures and Search Techniques

Efficient Query Processing: DBMS uses specialized data structures and
indexing techniques for faster query execution.

Buffering and Caching: Maintains parts of the database in main memory

buffers for quicker access.

Query Optimization: Optimizes query execution plans based on existing

storage structures, enhancing performance.

5. Providing Backup and Recovery

Resilience: DBMS provides facilities for recovering from hardware or
software failures, ensuring data integrity.

Backup Subsystem: Responsible for restoring the database to a consistent

state after failures occur.

6. Providing Multiple User Interfaces

User Accessibility: Offers a variety of user interfaces catering to different
user needs and technical abilities.

Mobile Apps, Query Languages, GUIs: DBMS supports mobile apps, query
languages, graphical user interfaces (GUIs), and other interfaces for
seamless user interaction.

7. Representing Complex Relationships among Data

Database Flexibility: A DBMS must handle complex relationships among
data efficiently.

Data Relationships: Enables representation of various relationships

between different data entities.

Efficient Retrieval and Updates: Allows for easy retrieval and updating of
related data, enhancing database functionality and usability.

8. Enforcing Integrity Constraints

Unit 1: Introduction to Database 11

 Data Integrity: DBMS should enforce integrity constraints to maintain data
consistency and accuracy.

Types of Constraints: Includes data type constraints, referential integrity

constraints, and uniqueness constraints.

Automatic Enforcement: Some constraints can be automatically enforced

by the DBMS, while others may require manual checks or update programs.

9. Permitting Inferencing and Actions Using Rules and Triggers

Rule-Based Systems: Some DBMSs support rule-based systems for
inferencing and actions.

Deductive Database Systems: Enable specifying deduction rules for

inferring new information.

Triggers and Stored Procedures: Triggers and stored procedures allow

automating actions based on specified conditions, enhancing database
functionality and responsiveness.

These additional features contribute to the efficiency, reliability, and

adaptability of database systems. Let me know if you need further explanation
or have any questions about these advantages!

1.7 A Brief History of Database Applications

The text outlines the evolution of database applications through various stages
of technological advancement:

7.1 Early Database Applications Using Hierarchical and Network

Systems
Conceptual Issues: Early systems intermixed conceptual relationships with
physical storage, hindering data abstraction and program-data
independence.

Programming Language Interfaces: Most systems provided only

programming language interfaces, making it cumbersome to implement
new queries and transactions.

Mainframe Era: Implemented on large and expensive mainframe computers

from the 1960s to the 1980s, based on hierarchical, network model, or
inverted file systems.

Unit 1: Introduction to Database 12

 7.2 Providing Data Abstraction and Application Flexibility with
Relational Databases
Relational Model: Proposed to separate physical storage from conceptual
representation and introduced high-level query languages.

Improved Flexibility: Relational databases allowed for faster query

development and database reorganization compared to earlier systems.

Performance Challenges: Early relational systems were slow but improved

with the development of new storage and indexing techniques.

7.3 Object-Oriented Applications and the Need for More

Complex Databases
Object-Oriented Databases (OODBs): Emerged in response to the need for
storing complex, structured objects.

Limited Adoption: Initially considered competitors to relational databases

but faced challenges due to complexity and lack of standards.

Incorporation into Relational Systems: Many object-oriented concepts

were integrated into relational databases, leading to object-relational
database management systems (ORDBMSs).

7.4 Interchanging Data on the Web for E-Commerce Using XML

E-Commerce on the Web: Emerged as a major application on the World
Wide Web, requiring dynamic extraction of data from DBMSs.

XML: Became a standard for interchanging data among databases and web
pages, combining document system and database modeling concepts.

7.5 Extending Database Capabilities for New Applications

Specialized Applications: Various applications such as scientific, image
and video storage, data mining, spatial, and time series applications
required specialized database capabilities.

Functional Extensions: DBMS developers added functionality to support

these specialized requirements, either as general-purpose enhancements
or optional modules.

7.6 Emergence of Big Data Storage Systems and NoSQL

Databases

Unit 1: Introduction to Database 13

 Big Data Era: The proliferation of data-intensive applications led to the
development of new database systems capable of managing large volumes
of nontraditional data.

NoSQL Databases: These systems, referred to as "Not Only SQL," were

designed to address the requirements of big data storage and retrieval,
sometimes in combination with traditional SQL systems.

This historical overview highlights the continuous evolution of database

technologies to meet the changing needs of applications and data
management. Let me know if you need further clarification on any part!

1.8 When Not to Use a DBMS

The overhead costs of using a DBMS are due to the
following:
■ High initial investment in hardware, software, and training
■ The generality that a DBMS provides for defining and processing data
■ Overhead for providing security, concurrency control, recovery, and integrity
function
Therefore, it may be more desirable to develop customized database
applications
under the following circumstances:
■ Simple, well-defined database applications that are not expected to change
at all
■ Stringent, real-time requirements for some application programs that may
not be met because of DBMS overhead
■ Embedded systems with limited storage capacity, where a general-purpose
DBMS would not fit
■ No multiple-user access to data

Industries and applications that have specific requirements or performance

demands sometimes opt not to use general-purpose DBMSs. For instance:

Computer-Aided Design (CAD) Tools: CAD tools often have proprietary file
and data management software tailored for handling drawings and 3D
objects efficiently.

Communication and Switching Systems: Systems designed for

telecommunications, like those by AT&T, historically used specialized

Unit 1: Introduction to Database 14

 database software optimized for hierarchical data organization to route
calls quickly.

Geographic Information Systems (GIS): GIS implementations may develop

their own data organization schemes to efficiently process maps, contours,
and spatial data.

2.1 Data Models, Schemas, and Instances

1. Data Abstraction and Data Models
Data Abstraction: Suppression of details of data organization and storage,
highlighting essential features for better understanding.

Database Approach: Supports data abstraction to enable different users to

perceive data at preferred levels of detail.

Data Model: Collection of concepts describing the structure of a database,

enabling abstraction.

Structure of Database: Encompasses data types, relationships, and

constraints.

Basic Operations: Includes operations for specifying retrievals and updates

on the database.

Dynamic Aspects: Some data models incorporate concepts for specifying

dynamic behavior of database applications.

2. Categories of Data Models

High-level or Conceptual Data Models: Concepts closer to user perception
of data.

Low-level or Physical Data Models: Concepts detailing data storage on

computer storage media.

Representational Data Models: Intermediate, providing concepts

understandable by end-users yet close to computer storage organization.

Conceptual Data Model Concepts: Entities, attributes, relationships.

Implementation Data Models: Utilized in traditional DBMSs; e.g., relational

data model, object data model.

Unit 1: Introduction to Database 15

 Physical Data Models: Describe data storage on computer, including
record formats, access paths.

Self-describing Data Models: Combine data description with data values

(e.g., XML, key-value stores).

3. Schemas, Instances, and Database State

Database Schema: Description of the database specified during design,
not expected to change frequently.

Schema Diagram: Displayed schema, showing structure but not instances.

Schema Construct: Each object in the schema (e.g., STUDENT, COURSE).

Database State: Actual data in a database at a particular moment.

Database Snapshot: Current set of occurrences or instances in the

database.

Database Evolution: Changes to the schema as application requirements

change; facilitated by schema evolution operations in modern DBMSs.

2.2 Three-Schema Architecture and Data

Independence
1. Internal Level
Internal Schema: Describes the physical storage structure of the database.

Characteristics: Utilizes a physical data model, provides complete details

of data storage and access paths.

2. Conceptual Level
Conceptual Schema: Describes the structure of the entire database for a
community of users.

Focus: Hides physical storage structures, emphasizes entities, data types,

relationships, user operations, and constraints.

Representation: Often based on a representational data model, derived

from high-level data model design.

Unit 1: Introduction to Database 16

 3. External Level
External Schema or User Views: Describes specific parts of the database
for individual user groups.

Purpose: Hides irrelevant data from each user group, focuses on their
specific interests.

Implementation: Typically utilizes a representational data model, based on

external schema design in a high-level conceptual data model.

Implementation and Use

DBMS Support: Most DBMSs partially support the three-schema
architecture.

Integration: External schemas may sometimes include physical-level

details.

Significance: Offers a clear separation between users' external view, the

database's conceptual level, and the internal storage level, aiding in
database design.

Mapping: DBMS transforms requests from external to conceptual, then to

internal schemas for processing.

Data Retrieval: If a retrieval, data extracted from the stored database needs
reformatting to match the user's external view.

Mappings Complexity: Transforming requests and results between levels

can be time-consuming.

DBMS Variations: Some systems, especially those for small databases,

may not fully support external views but still require transformations
between conceptual and internal levels.

Data Independence

1. Logical Data Independence

Definition: Ability to change the conceptual schema without impacting
external schemas or application programs.

Changes: Expansion (adding a record type or data item), constraints

alteration, or reduction (removing a record type or data item).

Unit 1: Introduction to Database 17

 Impact: External schemas referencing remaining data should remain
unaffected.

Example: Changing the GRADE_REPORT file in the conceptual schema

won't affect the external schema (Figure 1.5(a) vs. Figure 1.6(a)).

Implementation: Only view definition and mappings require modification in

DBMS supporting logical data independence.

Constraints: Alterations can be applied to the conceptual schema without

affecting external schemas or application programs.

2. Physical Data Independence

Definition: Ability to change the internal schema without impacting the
conceptual schema or external schemas.

Changes: Reorganization of physical files (e.g., creating additional access

structures) to enhance performance.

Impact: External schemas remain unchanged.

Example: Improving retrieval speed of SECTION records without altering

query requirements.

Existence: Generally present in most databases and file environments

where physical details are hidden from users.

Applications: Remain unaware of physical details such as data location,

storage encoding, compression, etc.

Implementation and Considerations

DBMS Catalog: Expanded to include mapping information among various
schema levels.

Mappings: Achieved through additional software referencing mapping

information in the catalog.

Data Independence: Ensured by changing mappings between schema

levels instead of altering higher-level schemas, thus avoiding the need to
modify application programs.

2.3.1 DBMS Languages

Unit 1: Introduction to Database 18

 Data Definition Language (DDL)
Purpose: Define conceptual and internal schemas.

Usage:

In some DBMSs: Used by DBA and designers to define both schemas.

Separation maintained: Used to specify conceptual schema only.

Other Languages:

Storage Definition Language (SDL): Specifies internal schema (not

common in relational DBMSs).

View Definition Language (VDL): Specifies user views and mappings

(often done with DDL in relational DBMSs).

Data Manipulation Language (DML)

Purpose: Manipulate data in the database (e.g., retrieval, insertion, deletion,
modification).

Integration:

Often part of a comprehensive integrated language along with DDL and

VDL.

Examples:

SQL: Represents a combination of DDL, VDL, and DML, with additional

features like constraint specification and schema evolution.

Types:

High-Level (Nonprocedural): Specifies complex operations concisely.

Low-Level (Procedural): Embedded in general-purpose programming

languages, processes individual records.

Host Language and Data Sublanguage

Host Language: General-purpose programming language in which DML
commands are embedded.

Data Sublanguage: DML embedded within the host language.

Query Language
Purpose: Used by casual end users to specify requests interactively.

Unit 1: Introduction to Database 19

 Usage:

High-level query language: Used standalone interactively.

Embedded in general-purpose programming languages for

programmers.

Interfaces:

User-friendly interfaces for naive and parametric users who don't want
to learn high-level query language details.

2.4.1 DBMS Component Modules

Overview:
Top Part: Interfaces for various users - DBA staff, casual users, application
programmers, and parametric users.

Lower Part: Internal modules of DBMS responsible for data storage and
transaction processing.

Top Part:
1. DBA Staff: Defines and tunes the database using Data Definition Language
(DDL) and other privileged commands.

2. Casual Users: Interact with interactive query interfaces to formulate

queries.

3. Application Programmers: Create programs using host programming

languages, submitted to precompiler.

4. Parametric Users: Perform data entry work by supplying parameters to

predefined transactions.

DDL Compiler:
Processes schema definitions specified in DDL.

Stores schema descriptions (meta-data) in the DBMS catalog.

Catalog includes various information needed by DBMS modules.

Query Compiler:
Validates and parses queries for correctness.

Unit 1: Introduction to Database 20

 Compiles queries into internal form for optimization.

Query Optimizer:
Rearranges and optimizes queries for efficient execution.

Consults system catalog for statistical and physical information about

stored data.

Precompiler:
Extracts Data Manipulation Language (DML) commands from host language
programs.

Sends DML commands to DML compiler for compilation into object code.

Runtime Database Processor:

Executes privileged commands, executable query plans, and canned
transactions with runtime parameters.

Works with system catalog and updates it with statistics.

Handles data transfer between disk and main memory, manages buffers.

Integrates concurrency control and backup/recovery systems for

transaction management.

Client-Server Architecture:
Client program accesses DBMS running on a separate database server.

Middle computer (application server) may be involved in accessing the

database server.

DBMS interacts with operating system, compilers, and network interface for
disk access, processing, and client-server communication.

2.4.6 Classification of Database Management

Systems
1. Based on Data Model:
Relational Data Model: Most common in commercial DBMSs, represented
by SQL systems.

Unit 1: Introduction to Database 21

 Object Data Model: Defines databases in terms of objects, properties, and
operations.

Object-Relational Systems: Evolution of relational DBMSs incorporating

object database concepts.

Big Data Systems (NOSQL): Utilize various models like key-value,

document-based, graph-based, and column-based.

Legacy Models: Hierarchical and network models still used in some legacy
applications.

XML (eXtended Markup Language) Model: Tree-structured model, used

for Web data exchange.

2. Based on Number of Users:

Single-user Systems: Support one user at a time, commonly used with
personal computers.

Multiuser Systems: Support concurrent multiple users.

3. Based on Distribution of Database:

Centralized DBMS: Data stored at a single computer site.

Distributed DBMS (DDBMS): Database and DBMS software distributed over

multiple sites.

Homogeneous DDBMS: Same DBMS software at all sites.

Heterogeneous DDBMS: Different DBMS software at each site.

Federated DBMS (Multidatabase System): Loosely coupled DBMSs

with local autonomy, accessed through middleware.

4. Based on Cost:
Open source (free) DBMS products like MySQL and PostgreSQL.

Commercial DBMSs available in various pricing models including site

licenses, per copy, and modular components.

5. Based on Access Path Options:

Some DBMSs based on inverted file structures.

6. General Purpose vs. Special Purpose:

Unit 1: Introduction to Database 22

 General Purpose: Serve a wide range of applications.

Special Purpose: Designed and built for specific applications, e.g., airline
reservations, telephone directory systems.

The classification of DBMSs helps in understanding their capabilities and

suitability for different application scenarios, ranging from personal use to
enterprise-level systems handling massive amounts of data.

Unit 1: Introduction to Database 23