Database management system

Introduction to DBMS

A Database Management System (DBMS) is specialized software that allows users to store, manage,
retrieve, and manipulate large amounts of structured data efficiently. It acts as an intermediary between users
and the database, ensuring that data is well-organized, easily accessible, and protected from unauthorized
access.

● Examples of DBMS: MySQL, Oracle, Microsoft SQL Server, PostgreSQL.

1. Manual File System

● Definition: In a manual file system, data is stored physically in hard copies, typically on paper. It
includes file cabinets, folders, and records.
● Management: Files are managed and retrieved manually, which is time-consuming and prone to
human error.
● Challenges:
○ Difficult to organize, locate, and retrieve specific data efficiently.
○ High risk of loss, damage, or duplication.
○ Data integrity and consistency are hard to maintain.
● Example: Storing employee details in physical folders, where each employee has a dedicated folder
containing their records.

2. Traditional File Processing System

● Definition: In a traditional file processing system, data is stored electronically, but files are maintained
independently and often do not interact with each other.
● Data Redundancy: The same data may be stored across multiple files, leading to redundancy.
● Challenges:
○ Data Inconsistency: If data is updated in one file, it may not be updated in another, causing
inconsistency.
○ Limited Data Sharing: Files are not interconnected, making it hard to share data across the
system.
○ Poor Scalability: Adding new types of data requires significant effort and often rework of the
entire structure.
● Example: Early payroll and inventory systems, where employee records or inventory data are stored in
separate files that do not communicate with one another.

3. Database Management System (DBMS)

● Definition: A DBMS is a software system that manages databases and allows multiple users to create,
retrieve, update, and manage data systematically and securely.
● Characteristics:
○ Data Integrity and Consistency: Centralized control ensures that data remains consistent and
accurate across all users.
○ Data Security: Access control mechanisms protect sensitive information.
 ○ Data Independence: Changes in database structure do not affect the application programs
using the data.
○ Minimized Redundancy: By centralizing data, a DBMS minimizes data duplication.
○ Support for Complex Queries: A DBMS allows complex queries and reports that are difficult
to achieve in file systems.
● Example: A relational DBMS like MySQL or PostgreSQL that stores and manages data for a
company's HR, payroll, and customer databases, allowing easy access and manipulation across
departments.

Comparison

Feature Manual File System Traditional File Processing DBMS

System
Data Storage Physical (paper files) Electronic files Centralized
database

Data Redundancy High High Low

Data Consistency Hard to maintain Limited Maintained by

DBMS

Data Security Low Moderate High

Data Access Manual Basic file operations Advanced query

language

Efficiency in Low Moderate High

Retrieval

Data Integrity Hard to ensure Moderate High

Data Sharing Limited Limited Extensive

Database Approach vs. Traditional File System

Feature Traditional File Processing Database Management System

System (DBMS)

Data Organization Data is stored in isolated, Data is stored in a structured

separate files, often with no manner using tables, schemas, and
inherent relationship between relationships, supporting easy
files. access and management.

Data Redundancy High redundancy; the same data Low redundancy; data is centralized
is often stored in multiple files. and managed to minimize
duplication
 Data Consistency Hard to maintain; changes in one Automatically maintained; DBMS
file do not automatically update in ensures updates are consistent
others, leading to inconsistency. across all related tables.

Data Integrity Difficult to enforce; constraints High integrity; constraints and rules
are managed manually, often (like primary keys and foreign keys)
leading to data entry errors. enforce data accuracy and
consistency.

Data Security Limited security; access controls Strong security; DBMS supports
are usually minimal and file- user roles, permissions, and
based. encryption to protect data.

Data Sharing Limited sharing; each file is High sharing capability; DBMS
typically isolated and managed allows concurrent access by
independently. multiple users and applications.

Data Low data independence; changes High data independence; DBMS

Independence to file structure often require abstracts physical data storage from
modifications in application logical structure, making changes
programs. easier.

Data Retrieval Generally slower and less High efficiency; DBMS supports
Efficiency efficient, requiring custom file complex queries with SQL, allowing
handling code. faster data retrieval.

Data Backup and Typically manual; prone to errors Automated; DBMS supports regular
Recovery and inconsistencies. backup and robust recovery
options.

Support for No built-in support; transactions Built-in support for ACID properties
Transactions need to be managed at the (Atomicity, Consistency, Isolation,
application level, leading to Durability), ensuring data reliability.
complexity.

Scalability Limited scalability; difficult to Highly scalable; DBMS can manage

handle large amounts of data. large datasets efficiently.

Advantages of Database Systems

1. Data Redundancy Control

○ In traditional file systems, data redundancy—where the same data is stored in multiple places—
is a common issue. DBMS minimizes redundancy by centralizing data, allowing different users
and applications to access the same data from a single source. This not only saves storage
space but also simplifies updates and maintenance, as changes in one place automatically
reflect across the system.
2. Data Consistency
○ A DBMS enforces data consistency by ensuring that data across various tables and
relationships remains accurate and up-to-date. Consistency constraints (like unique keys,
foreign keys, and checks) prevent unauthorized or incorrect data entries, leading to higher
reliability in data.
3. Data Integrity
○ Integrity constraints are used to ensure the accuracy and reliability of data in the database. For
instance, constraints like primary keys, foreign keys, and validation rules prevent invalid data
 entries. This ensures that the data maintains its validity over time, contributing to accurate and
meaningful information.
4. Enhanced Data Security
○ DBMS allows for controlled access to sensitive data, restricting data based on user roles and
permissions. Multi-level access control ensures that users see only the data they’re authorized
to access. This level of security is critical in environments where data privacy and confidentiality
are priorities, such as finance, healthcare, and government.
5. Data Sharing and Multi-User Environment
○ Modern DBMS systems are designed for multi-user environments, allowing several users to
access and manipulate data concurrently. This makes them ideal for collaborative applications
where multiple users need real-time access to shared data. Mechanisms like locking, isolation
levels, and transaction control prevent data conflicts in a multi-user setup.
6. Efficient Data Retrieval and Querying
○ One of the primary strengths of a DBMS is its ability to quickly retrieve data through Structured
Query Language (SQL). Users can execute complex queries to find and manipulate data, even
if they are spread across multiple tables. Indexing, stored procedures, and optimization
techniques in DBMS further enhance query performance.
7. Backup and Recovery Mechanisms
○ DBMSs typically include built-in support for automatic data backups and recovery. In case of a
system failure, data can be restored to a stable state without significant loss. This is crucial for
businesses that rely on continuous data availability.
8. Data Independence
○ A DBMS provides logical and physical data independence, meaning that the way data is stored
physically can be altered without affecting how it is accessed by applications. This flexibility
allows changes to be made at the data structure level without requiring application-level
modifications, making system maintenance easier.
9. Transaction Management and ACID Compliance
○ Database systems support transactions, ensuring that a group of related tasks is completed
successfully before data is committed to the database. ACID (Atomicity, Consistency, Isolation,
Durability) properties provide reliable and safe transaction processing, which is essential for
applications that require high levels of data accuracy and security.
10. Scalability and Flexibility
○ DBMSs are scalable, meaning they can grow with the application’s needs by managing larger
volumes of data efficiently. This makes them suitable for applications of various sizes, from
small-scale systems to large enterprise solutions.

Disadvantages of Database Systems

1. Complexity
○ Database systems are inherently complex, requiring a deep understanding of data modeling,
schema design, indexing, and query optimization. Skilled personnel are necessary to design,
maintain, and troubleshoot database systems, making the learning curve steep and potentially
limiting access to those with the requisite expertise.
2. Cost of DBMS Software and Hardware
○ Setting up a DBMS involves significant upfront costs, including software licenses, hardware for
hosting, and storage infrastructure. Enterprise-level DBMSs like Oracle and SQL Server require
licensing fees, which can be costly for small to medium-sized businesses. Additional hardware
expenses may be necessary for high-performance databases.
3. Performance Overhead
○ While DBMSs optimize many aspects of data handling, they can introduce overhead due to
complex queries, locking mechanisms, transaction management, and data retrieval processes.
 For small applications, the performance overhead may outweigh the benefits, making simpler
solutions more efficient in such cases.
4. Data Security Risks
○ Despite robust security measures, centralized databases can become targets for cyberattacks.
Sensitive data in a DBMS can attract threats, and a single vulnerability could lead to substantial
data breaches. This requires continuous monitoring, security audits, and software updates to
mitigate risks, which can be resource-intensive.
5. Potential Data Loss Risks
○ A DBMS usually provides backup and recovery mechanisms, but they are not foolproof. If
backups are not performed regularly, or if data corruption occurs during the backup process,
data could be lost. In large systems, even temporary data loss can result in downtime and
disrupt business continuity.
6. Impact of System Failure
○ The centralized nature of a DBMS means that a failure in the system can impact the entire
organization, affecting data availability and productivity. Although recovery options are
available, system failures may result in delays or interruptions to critical operations, especially
in time-sensitive applications.
7. Data Migration Challenges
○ Migrating data from legacy systems to a DBMS or from one DBMS to another can be complex
and prone to errors. Data transformations, mapping, and migration tools may be necessary,
and maintaining data integrity and consistency during migration requires meticulous planning
and testing.
8. Complexity of Database Design
○ Poorly designed databases can lead to inefficiency, redundancy, and data inconsistency. Initial
database design requires careful consideration of relationships, data normalization, and
indexing strategies. A flawed database design can be challenging and expensive to rectify later
on.
9. Requirement for Regular Maintenance and Updates
○ Database systems require continuous maintenance, including regular updates, security
patches, and performance tuning. Failure to maintain the system properly can lead to
decreased performance, security vulnerabilities, and data inconsistencies, which can directly
impact business operations.
10. Limited Support for Non-Structured Data
○ Traditional relational DBMSs are not well-suited for handling unstructured data (e.g.,
multimedia, complex documents). Although some modern DBMSs offer support for non-
relational data structures, it remains limited compared to specialized NoSQL databases, which
are better suited for big data applications involving unstructured data.

Data Models

A Data Model defines how data is structured, stored, and accessed within the database. It provides the logical
structure for organizing data.
1. Object-Based Data Models

These models describe data at a high level, using concepts from object-oriented programming or entity
relationships.

a) Object-Oriented Model

● Description: The object-oriented model is based on objects, classes, and inheritance, similar to
object-oriented programming. This model stores data in the form of objects, which represent real-world
entities.
● Use Cases: Commonly used in applications that involve complex data structures, like multimedia
applications, CAD (Computer-Aided Design), or telecommunications.
● Example: Suppose we have a "Student" class with properties like name, studentID, and courses.
Each student object will have unique data for these properties.

○ In the above diagram, each "Student" object has attributes (like name, age) and methods (like
register(), updateInfo()).
b) Entity-Relationship (ER) Model

● Description: The ER model is used to define the data elements and their relationships. It uses entities
(objects) and relationships to represent data.
● Use Cases: Primarily used during database design to visually map out data requirements before
database creation. Ideal for relational databases.
● Example: In a university database, we may have entities like Student, Course, and Professor,
with relationships like enrolls_in and teaches.

○ In the ER diagram above, entities (Student, Course) are connected by relationships

(enrolls_in). Each entity has attributes.
2. Record-Based Data Models

These models organize data in fixed formats or records. Each record type defines a fixed number of fields or
attributes.

a) Relational Model

● Description: Data is organized into tables (or relations) with rows and columns. Each row is a unique
record, and each column represents an attribute. Relationships are established by keys.
● Use Cases: Widely used in business and industry applications because of its simplicity, flexibility, and
robustness. Most SQL databases (like MySQL, PostgreSQL) use this model.
● Example: Consider a Customer table with columns like customer_id, name, and email.
b) Network Model

● Description: Represents data as a network of records connected by links. It supports many-to-many

relationships, where each record can have multiple parent and child records.
● Use Cases: Suitable for complex applications like telecommunications and manufacturing. Rarely used
in modern systems but was popular in legacy databases.
● Example: A database with departments and employees, where an employee can work in multiple
departments.
○ In this network diagram, an employee might belong to multiple departments, represented by
connecting nodes with lines.
c) Hierarchical Model

● Description: Organizes data in a tree-like structure where each record has a single parent and
potentially multiple children. Each child record can only have one parent.
● Use Cases: Suitable for applications with hierarchical data, like file systems and organization charts.
● Example: Consider an organizational chart with CEO at the top, followed by Managers, and then
Employees.

○ Each level represents a hierarchy, like CEO > Manager > Employee.
3. Physical Data Models

These models focus on the physical storage structure of data and are less concerned with logical data
structures.

a) Unifying Model

● Description: The unifying model is a framework designed to integrate various types of data models,
providing a unified approach to data storage and retrieval at a physical level.
● Use Cases: Used in databases where a common framework is needed to handle diverse data models
and access methods. It’s complex and usually applicable to specific industries or high-level database
implementations.
● Example: No single example, but can be visualized as a framework that supports both relational and
network data for diverse operations.

b) Frame Memory Model

● Description: This model is more common in databases that prioritize memory usage optimization and
fast data retrieval. Data is stored in structures optimized for in-memory operations.
● Use Cases: Suitable for applications requiring rapid access to data, such as real-time analytics and
high-speed transaction systems.
● Example: Frame memory structures are used in high-performance, memory-intensive applications like
AI systems that need to pull data in real-time from memory rather than disk storage.

Comparing hierarchical, network, and relational data models

Feature Hierarchical Data Network Data Relational Data

Model Model Model
Structure Tree-like structure, Graph-like structure Table-based, data
with a single parent allowing multiple organized into rows
per child parent-child and columns
relationships

Data Relationships One-to-many (each Many-to-many (each Flexible relationships,

child has only one record can have typically using
parent) multiple parents and primary and foreign
children keys

Navigation Navigated through Navigated using Uses SQL queries for

parent-child pointers pointers or sets, flexible data access
more complex than and navigation
hierarchical

Flexibility Limited, rigid More flexible than Highly flexible, easy

hierarchy hierarchical but still to add relationships
complex or modify structure

Data Integrity Good for strict Can maintain Strong data integrity
hierarchical complex relationships with constraints,
relationships, lacks but difficult to normalization
flexibility manage possible

Example Uses XML files, IBM IMS Early database Most modern
systems like databases (e.g.,
CODASYL MySQL, PostgreSQL,
Oracle)

Advantages Simple, efficient for Suitable for complex Highly flexible, widely
hierarchical data relationships supported, easy to
use and modify

Disadvantages Limited in handling Complex Can require

complex management and significant storage,
relationships navigation, high may have slower
maintenance query performance
 Popular Systems IBM Information IDMS (Integrated MySQL, PostgreSQL,
Management System Database Oracle, SQL Server
(IMS) Management
System)

Schemas and Instances

In Database Management Systems (DBMS), a schema is the structure that defines the organization of data in
a database. It describes how data is stored, organized, and how the relationships among data are managed.
Think of it as a blueprint for how the database is set up and how data is logically organized within it.

Types of Schemas in DBMS

There are generally three levels of schema in a DBMS:

1. Physical Schema: Defines the physical storage structure of data on storage devices. For example,
how tables are stored on disk.
2. Logical Schema: Defines the logical structure of the database, such as tables, columns, data types,
and relationships between tables. It represents what data is stored and the relationships, but not how it
is physically stored.
3. View Schema: Defines the subset of the database visible to specific users or applications. It might
restrict access to certain columns or rows in a table, or it might combine data from multiple tables into
one view.
 Examples of Schemas

● E-commerce Database Schema

○ Tables: Users, Products, Orders, Order_Details, Payments.
○ Relationships:
■ Each Order is associated with a User and contains multiple Order_Details entries for
products.
■ Each Product can appear in multiple Order_Details.
■ Payments are linked to specific Orders.
● University Database Schema
○ Tables: Students, Courses, Professors, Enrollment, Departments.
○ Relationships:
■ Each Student can enroll in multiple Courses through the Enrollment table.
■ Each Course is taught by a Professor and belongs to a Department.
● Library Management System Schema
○ Tables: Books, Authors, Members, Loans.
○ Relationships:
■ Each Book can be authored by multiple Authors.
■ Members can borrow Books through the Loans table, where the loan date and return
date are tracked.

A database schema is designed by a database designer (often called a database administrator (DBA) or
data architect). This schema provides a structured layout of the data, defining how the data is organized,
related, and constrained within the database.

In DBMS (Database Management System), an instance refers to a specific occurrence of the database at a
particular point in time. It consists of the data stored in the database, which can change over time as the
database is updated. The database instance represents the actual content of the database as it exists at that
moment, including all the tables, rows, columns, and their values.

To clarify, there are two key components when we talk about databases in DBMS:

1. Database schema: The structure or design of the database, which includes the definitions of
tables, relationships, views, etc. It remains constant.
2. Database instance: The data stored in the database at any given time. It changes as records are
inserted, updated, or deleted.
Three schema Architecture in DBMS
The Three-Level Architecture of a Database Management System (DBMS) is also known as the Three-
Level Schema Architecture. It divides the database into three levels of abstraction: External Schema,
Logical Schema, and Internal Schema. This architecture is designed to provide data independence,
meaning changes in one level should not directly affect other levels.
The Three Schema Architecture is a framework in database management systems (DBMS) used to separate
a database's internal, conceptual, and external views, allowing for data abstraction, data independence, and
database flexibility. Proposed by the ANSI/SPARC in the 1970s, it organizes how data is stored, managed,
and presented to users. Here’s an overview:

1. Internal Schema (Physical Schema)

● Purpose: Manages how data is physically stored on storage devices.

● Details: Describes storage structures, indexing, data access paths, and performance optimization
techniques. It includes the hardware aspects of storage, such as file structures, data blocks, and
memory management.
● Users: Database administrators and system developers.
● Focus: Efficiency and storage optimization, detailing data structures like tables, columns, data types,
etc., but from a physical perspective.

2. Conceptual Schema (Logical Schema)

● Purpose: Represents the structure of the entire database for the community of users.
● Details: Defines entities, relationships, data constraints, and rules governing the data, abstracted from
physical details.
● Users: Database designers and administrators.
● Focus: Logical organization and database independence, aiming for a unified, consistent view of the
database, describing what data is stored and its relationships.

3. External Schema (View Level)

● Purpose: Provides tailored views of the database for different user groups or applications.
● Details: Contains a subset of the database, defining how specific users interact with the data. Users
might see only the data relevant to their tasks.
● Users: End-users and application programs.
● Focus: Ensuring data security and customized access, hiding irrelevant data, and simplifying complex
data structures for different users or applications.

Benefits of Three Schema Architecture

● Data Abstraction: Separates data models at different levels, simplifying complex database systems.
● Data Independence: Supports physical and logical independence, allowing changes at one level
without affecting others.
● Security and Customization: Ensures that users access only the data they need, enhancing data
security and user experience.

The Three Schema Architecture is crucial in complex databases, enabling flexibility, maintainability, and user-
specific data customization without affecting the overall database integrity.

Types of Users in Database

1. Database Administrators (DBAs)

● Role: The DBA is responsible for managing, maintaining, and securing the database. They play a
crucial role in ensuring data integrity, availability, and performance within the organization.
● Tasks:
○ Installation and Configuration: Setting up the DBMS software and configuring it according to
organizational requirements.
○ Backup and Recovery: Implementing backup procedures and planning for data recovery in
case of failures.
○ User Management: Creating and managing user accounts, permissions, and roles to control
access to the database.
○ Performance Monitoring: Continuously monitoring database performance, optimizing queries,
and tuning the system for better efficiency.
○ Security Enforcement: Setting up security protocols, such as encryption and access control,
to protect sensitive data.
● Skills Needed: Knowledge of database languages (e.g., SQL), system architecture, data security, and
DBMS-specific tools.

2. Application Programmers / Back-End Developers

● Role: Application programmers, or back-end developers, build and maintain the applications that
interact with the database. They create software solutions that query, update, and manipulate the data
as per the application’s requirements.
● Tasks:
○ Coding Database Interactions: Writing code to perform CRUD (Create, Read, Update,
Delete) operations on the database.
○ API Development: Developing APIs (Application Programming Interfaces) that interact with the
database, facilitating data access for front-end or client applications.
 ○ Optimization: Writing optimized queries and procedures to ensure efficient data retrieval and
manipulation.
○ Data Validation: Ensuring data integrity by implementing input validation and error handling.
● Skills Needed: Proficiency in programming languages (e.g., Python, Java, or PHP), SQL, API
development, and familiarity with database structures.

3. Naive Users / Parametric Users

● Role: Naive or parametric users are end-users who interact with the database regularly but do not
need specialized knowledge of database operations. They use predefined applications or forms to
perform simple operations.
● Tasks:
○ Routine Data Entry: Using forms and interfaces to add new data to the database.
○ Data Retrieval: Running predefined queries or reports to retrieve information.
○ Simple Updates: Making minor updates or corrections to existing data through interfaces.
● Skills Needed: Basic knowledge of the application interface and data entry; typically, no knowledge of
SQL or programming is required.

4. Sophisticated Users

● Role: Sophisticated users are experienced professionals, such as data analysts or scientists, who
have an in-depth understanding of the database and may perform complex data analysis, reporting,
and research.
● Tasks:
○ Ad Hoc Querying: Writing complex SQL queries to extract specific data for analysis.
○ Advanced Data Manipulation: Utilizing advanced SQL functions, joins, subqueries, and views
to analyze or manipulate data.
○ Report Generation: Generating complex reports or visualizations that help in decision-making.
○ Data Science and Analysis: Using the database for predictive modeling, machine learning, or
statistical analysis.
● Skills Needed: Proficiency in SQL, statistical or data analysis tools (e.g., R, Python), knowledge of
data structures, and familiarity with business intelligence (BI) tools.

5. System Analysts

● Role: System analysts are responsible for assessing the needs of users and designing database
solutions that meet those requirements. They work with both technical and non-technical staff to
ensure the database aligns with business objectives.
● Tasks:
○ Requirements Gathering: Collaborating with stakeholders to understand their data needs and
documenting requirements.
○ System Design: Designing database structures, including tables, schemas, and relationships,
based on the project requirements.
○ Specification of Workflows: Outlining processes, workflows, and data flow diagrams to define
how data moves through the system.
○ Testing and Quality Assurance: Testing database functionality and working with developers
to resolve issues or make improvements.
● Skills Needed: Strong analytical skills, knowledge of data modeling techniques, familiarity with system
design principles, and experience with project management.
Each of these roles contributes to the effective use, maintenance, and security of the database system
in a unique way, ensuring it remains a reliable and valuable asset for the organization.

roles and responsibilities of a Database Administrator (DBA)

1. Database Setup and Configuration

● Role: Install, configure, and set up the database management system (DBMS) according to the
organization's needs.
● Responsibilities:
○ Install DBMS software and apply patches or updates.
○ Configure database settings for optimal performance and security.

2. Performance Monitoring and Optimization

● Role: Monitor database performance and make necessary adjustments to improve efficiency.
● Responsibilities:
○ Analyze and optimize slow queries and database response times.
○ Implement indexing, partitioning, and other techniques to enhance performance.
○ Use monitoring tools to track performance metrics (e.g., CPU usage, memory usage, and disk
I/O).

3. Data Security Management

● Role: Protect the database from unauthorized access and data breaches.
● Responsibilities:
○ Set up access controls, authentication, and authorization protocols.
○ Regularly audit permissions and enforce security policies.
○ Apply encryption for sensitive data and ensure secure data storage and transfer.

4. Backup and Recovery Management

● Role: Ensure data backups are available and reliable for data recovery.
● Responsibilities:
○ Design and implement backup strategies based on data importance and frequency of changes.
○ Regularly test backup and restore processes.
○ Plan for disaster recovery and minimize downtime in case of failure.

5. Data Integrity and Quality Control

● Role: Ensure data accuracy, consistency, and reliability within the database.
● Responsibilities:
○ Enforce data validation, constraints, and triggers to maintain data integrity.
○ Monitor data quality and conduct regular audits to detect and correct inconsistencies.
○ Define data standards and enforce them for consistency.

6. User Access and Account Management

● Role: Manage and control access to the database for users.

 ● Responsibilities:
○ Create, modify, and remove user accounts as needed.
○ Assign roles and permissions based on user responsibilities.
○ Monitor user activity to detect unauthorized access or suspicious actions.

7. Troubleshooting and Issue Resolution

● Role: Diagnose and resolve database-related issues to ensure availability.

● Responsibilities:
○ Identify and fix database errors, connection issues, and performance problems.
○ Work with developers to resolve issues related to SQL queries or application interaction.
○ Provide support for system-related or data integrity issues affecting the database.

8. Capacity Planning and Forecasting

● Role: Plan for future database storage and performance needs.

● Responsibilities:
○ Monitor current storage and anticipate future capacity requirements.
○ Develop a growth plan based on usage patterns and expected data volume.
○ Coordinate upgrades or changes to the infrastructure to support increased demand.

9. Documentation and Reporting

● Role: Maintain records and reports for database operations and configurations.
● Responsibilities:
○ Document database configurations, procedures, and troubleshooting guidelines.
○ Prepare regular reports on database performance, usage, and user activity.
○ Maintain logs of system changes, patches, and maintenance activities.

10. Compliance and Regulatory Adherence

● Role: Ensure the database complies with legal and regulatory standards.
● Responsibilities:
○ Enforce data privacy and retention policies according to regulations (e.g., GDPR, HIPAA).
○ Conduct regular audits and reviews to ensure compliance with legal standards.
○ Collaborate with compliance officers to address data security and privacy concerns.

Data Independence
Data Independence is a fundamental concept in database management systems (DBMS) that allows data
structures to be modified without requiring changes to the applications that access the data. This concept
helps maintain a separation between the data itself and how it is stored or accessed. There are two primary
types of data independence:

1. Logical Data Independence

● Definition: Logical data independence is the capacity to change the conceptual schema (logical
structure) without altering the external schemas or application programs.
● Example: Adding or removing fields (attributes) in a table or changing the relationships between tables
without affecting the applications that use the database. For instance, if a new field is added to a
customer table, applications using other fields in the table do not need to be modified.
● Purpose: This allows the database to evolve over time by modifying its logical structure without
needing to rewrite application code, preserving application stability and longevity.

2. Physical Data Independence

● Definition: Physical data independence is the ability to change the internal schema (how data is
physically stored) without needing to alter the conceptual schema or application programs.
● Example: Moving a database to a different storage device, changing the way data is indexed, or
reorganizing the storage format can be done without affecting how applications access the data or how
it’s logically represented.
● Purpose: Physical data independence ensures that performance optimizations and storage changes
do not impact application code or the logical structure, making database maintenance and tuning
easier.
Benefits of Data Independence

● Flexibility: Allows the database structure to adapt over time with minimal impact on existing
applications.
● Cost Efficiency: Reduces the need for costly rewrites of application code when database
modifications are needed.
● Easier Maintenance: Enhances database maintainability by isolating physical storage and logical
organization concerns from application design.

In short, data independence helps decouple data storage and retrieval from data usage, allowing changes in
one area without affecting others and supporting scalable, maintainable database systems.

Database Languages in DBMS

1. Data Definition Language (DDL)

○ DDL stands for Data Definition Language. It is used to define database structure or pattern.
○ It is used to create schema, tables, indexes, constraints, etc. in the database.
○ Using the DDL statements, you can create the skeleton of the database.
○ Data definition language is used to store the information of metadata like the number of tables
and schemas, their names, indexes, columns in each table, constraints, etc.

Here are some tasks that come under DDL:

○ Create: It is used to create objects in the database.

○ Alter: It is used to alter the structure of the database.
○ Drop: It is used to delete objects from the database.
○ Truncate: It is used to remove all records from a table.
 ○ Rename: It is used to rename an object.
○ Comment: It is used to comment on the data dictionary.

These commands are used to update the database schema that's why they come under Data definition
language.

2. Data Manipulation Language (DML)

DML stands for Data Manipulation Language. It is used for accessing and manipulating data in a
database. It handles user requests.

Here are some tasks that come under DML:

○ Select: It is used to retrieve data from a database.

○ Insert: It is used to insert data into a table.
○ Update: It is used to update existing data within a table.
○ Delete: It is used to delete all records from a table.
○ Merge: It performs UPSERT operation, i.e., insert or update operations.
○ Call: It is used to call a structured query language or a Java subprogram.
○ Explain Plan: It has the parameter of explaining data.
○ Lock Table: It controls concurrency.

3. Data Control Language (DCL)

○ DCL stands for Data Control Language. It is used to retrieve the stored or saved data.
○ The DCL execution is transactional. It also has rollback parameters.

(But in Oracle database, the execution of data control language does not have the feature of rolling back.)
Here are some tasks that come under DCL:

○ Grant: It is used to give user access privileges to a database.

○ Revoke: It is used to take back permissions from the user.

There are the following operations which have the authorization of Revoke:

CONNECT, INSERT, USAGE, EXECUTE, DELETE, UPDATE and SELECT.

4. Transaction Control Language (TCL)

TCL is used to run the changes made by the DML statement. TCL can be grouped into a logical
transaction.

Here are some tasks that come under TCL:

○ Commit: It is used to save the transaction on the database.

○ Rollback: It is used to restore the database to originality since the last Commit.
 Database Interface

A database management system (DBMS) interface is a user interface that allows for the ability to input queries
to a database without using the query language itself. User-friendly interfaces provided by DBMS may include
the following:

1. Menu-Based Interfaces
2. Forms-Based Interfaces
3. Graphical User Interfaces
4. Natural Language Interfaces
5. Speech Input and Output Interfaces
6. Interfaces for the Database Administrator (DBA)

Menu-Based Interfaces

These interfaces present the user with lists of options (called menus) that lead the user through the formation
of a request. The basic advantage of using menus is that they remove the tension of remembering specific
commands and syntax of any query language. The query is basically composed step by step by collecting or
picking options from a menu that is shown by the system. Pull-down menus are a very popular technique in
Web-based interfaces. They are also often used in browsing interfaces which allow a user to look through the
contents of a database in an exploratory and unstructured manner.

Forms-Based Interfaces

A forms-based interface displays a form to each user. Users can fill out all of the form entries to insert new
data, or they can fill out only certain entries, in which case the DBMS will redeem the same type of data for
other remaining entries. These types of forms are usually designed or created and programmed for users that
have no expertise in operating systems. Many DBMS’s have form specification languages which are special
languages that help specify such forms.

Example: SQL Forms is a form-based language that specifies queries using a form designed in conjunction
with the relational database schema.

Graphical User Interface

A GUI typically displays a schema to the user in diagrammatic form. The user then can specify a query by
manipulating the diagram. In many cases, GUI utilizes both menus and forms. Most GUI use a pointing device
such as a mouse, to pick a certain part of the displayed schema diagram.

Natural Language Interfaces

These interfaces accept requests written in English or some other language and attempt to understand them.
A Natural language interface has its own schema, which is similar to the database conceptual schema as well
as a dictionary of important words.

The natural language interface refers to the words in its schema as well as to the set of standard words in a
dictionary to interpret the request. If the interpretation is successful, the interface generates a high-level query
corresponding to the natural language and submits it to the DBMS for processing, otherwise, a dialogue is
started with the user to clarify any provided condition or request. The main disadvantage of this is that the
capabilities of this type of interface are not that advanced.

Speech Input and Output Interfaces

There is limited use of speech be it for a query or an answer to a question or being a result of a request it is
becoming commonplace. Applications with limited vocabulary such as inquiries for telephone directory, flight
arrival/departure, and bank account information are allowed speech for input and output to enable ordinary
folks to access this information.

The Speech input is detected using predefined words and used to set up the parameters that are supplied to
the queries. For output, a similar conversion from text or numbers into speech takes place.

Interfaces for Database Administrators (DBA)

Most database systems contain privileged commands that can be used only by the DBA’s staff. These include
commands for creating accounts, setting system parameters, granting account authorization, changing a
schema, and reorganizing the storage structures of databases.

Functions of DBA and Designer

Database Administrator (DBA)

The DBA is responsible for the maintenance, security, and operational performance of the database. Key
functions include:

1. Database Maintenance and Optimization: Ensures that databases are functioning optimally by
monitoring performance, tuning the database, and performing routine maintenance tasks.
2. Security and Access Control: Manages database access, ensuring only authorized users can access
or modify data. They also implement security measures to protect against unauthorized access and
breaches.
3. Backup and Recovery: Develops and maintains backup procedures and recovery plans to safeguard
data integrity in case of a system failure or data loss.
4. Data Integrity and Compliance: Ensures data accuracy and consistency across the database. They
also enforce compliance with data governance and regulatory requirements.
5. Troubleshooting and Support: Identifies and resolves database issues, providing support to users
and development teams.
6. Capacity Planning and Scalability: Monitors database growth and usage patterns to plan for scaling
and future resource requirements.

Database Designer

The Database Designer, often working closely with the DBA, is primarily focused on the structural and logical
design of the database. Key functions include:

1. Database Schema Design: Defines the overall structure of the database, including tables,
relationships, constraints, and keys based on data requirements.
2. Normalization and Optimization: Designs tables to minimize redundancy and improve efficiency,
ensuring data is organized logically.
3. Data Modeling: Creates data models and diagrams (like ER diagrams) to map out entities,
relationships, and data flow within the system.
 4. Standards and Documentation: Establishes standards for naming conventions, table structures, and
relationships, and documents the database structure for future reference.
5. Support Development: Works with application developers to ensure the database structure supports
application needs and can evolve with new features or data requirements.
6. Data Consistency and Integrity Design: Establishes constraints and rules in the design phase to
maintain data consistency and enforce business rules.

ER (Entity-Relationship) Data Models

➔ Peter Chen developed the ER diagram in 1976. The ER model was created to provide a
simple and understandable model for representing the structure and logic of databases. It has
since evolved into variations such as the Enhanced ER Model and the Object Relationship
Model
➔ The Entity Relational Model is a model for identifying entities to be represented in the
database and representation of how those entities are related. The ER data model specifies
an enterprise schema that represents the overall logical structure of a database graphically.
➔ The Entity Relationship Diagram explains the relationship among the entities present in the
database. ER models are used to model real-world objects like a person, a car, or a company
and the relation between these real-world objects. In short, the ER Diagram is the structural
format of the database.

Why Use ER Diagrams In DBMS?

1. ER diagrams represent the E-R model in a database, making them easy to convert into
relations (tables).
2. ER diagrams provide the purpose of real-world modeling of objects which makes them
intently useful.
3. ER diagrams require no technical knowledge and no hardware support.
4. These diagrams are very easy to understand and easy to create even for a naive user.
5. It gives a standard solution for visualizing the data logically.

Components of ER Diagram

ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.
ER diagram has three main components:

● Entity
● Attribute
● Relationship

Entity

Any object that physically exists and is logically constructed in the real world is called an
entity. It is a real-world object that can be easily identifiable. An entity is represented as a
rectangle in an ER diagram.

Example- In an organization, employees, managers, and projects assigned can be

considered entities. All these entities have some attributes or properties that give them their
identity.

Entities are of two types:

● Strong Entity – Strong entities are those entity types that have a key attribute. The
primary key helps in identifying each entity uniquely. this can not accept null values so
it can not be a unique key. It is represented by a rectangle.

Example – in an example of organization emp_id identifies each employee of the

organization uniquely and hence, we can say that employee is a strong entity type.
 ● Weak Entity – Weak entity type doesn’t have a key attribute. Weak entity types can’t be
identified on their own. It depends upon some other strong entity for its distinct identity.
A weak entity is represented by a double outlined rectangle. The relationship between
a weak entity type and strong entity type is shown with a double outlined diamond
instead of a single outlined diamond. This representation can be seen in the example
given below.

Attribute

Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB,
Age, Address, and Mobile_No are the attributes that define entity type Student. In the ER
diagram, the attribute is represented by an oval.

Example: Employee has attributes like name, age, roll,emp_id, and many more. To uniquely
identify the employee, we use the primary key as an emp_id(employee id) as it is not
repeated. Attributes can also be subdivided into another set of attributes.

types of attributes:

● Identifying attribute
● Descriptive attributes
● Simple attribute
● Composite attribute
● Single-valued attribute
● Multi-valued attribute
● Derived attribute.

1. Identifying Attribute

● Identifying attributes are essential for uniquely distinguishing each record or instance
within an entity. These attributes are commonly represented by primary keys in
databases.
● Example: In a university database, "Student ID" serves as an identifying attribute since
each student has a unique ID number. Even if two students share the same name,
their IDs allow for unique identification.

2. Descriptive Attribute

● Descriptive attributes add extra details or characteristics about an entity without

providing unique identification. They enrich the data by providing attributes that
describe the entity in various ways.
● Example: In a customer database, "Customer Address" and "Email Address" are
descriptive attributes. These attributes give more insight into the customer’s location
and contact information but don’t serve as a unique identifier.
3. Simple Attribute

● Simple attributes hold single, indivisible values, making them atomic. These attributes
are not divided into sub-parts.
● Example: In an employee record, "Gender" is a simple attribute with a value like
"Male" or "Female." Similarly, "Nationality" is also simple, as it represents a single
piece of information.

4. Composite Attribute

● Composite attributes consist of multiple sub-parts or components that together form a

single attribute. Each component in a composite attribute can have individual meaning
and might be used separately when needed.
● Example: "Address" might be a composite attribute with sub-components like "Street,"
"City," "State," and "Postal Code." Each sub-component gives more detail and can be
accessed individually for specific purposes, like filtering by city or postal code.

5. Single-Valued Attribute

● Single-valued attributes hold only one value per entity instance, ensuring each instance
has only a single, distinct value for that attribute.
● Example: In a library system, "Date of Membership" for a library member is a single-
valued attribute, as each member has only one date of joining the library. It helps in
tracking their membership duration and benefits.

6. Multi-Valued Attribute

● Multi-valued attributes can hold multiple values for a single entity instance. These
attributes are often represented as arrays or sets to accommodate multiple entries.
● Example: In an employee database, "Skills" could be a multi-valued attribute if an
employee has various skills like "JavaScript," "Python," and "Data Analysis." Storing
multiple skills under one attribute is beneficial for representing a person’s full range of
abilities.

7. Derived Attribute

● Derived attributes are not stored directly in the database; they are calculated or derived
from other stored attributes. This is useful to avoid redundant data and keep storage
efficient.
● Example: "Age" can be derived from a "Date of Birth" attribute. Instead of storing
"Age," it can be calculated as the difference between the current date and the birth
date whenever it’s needed, ensuring the value remains accurate without needing
updates.
Relationship

A relationship in a DBMS is primarily the way two or more data sets are linked. Relationships
allow the datasets to share and store data in separate tables. They also help link disparate
data with each other.

A relationship, in the context of databases, is a situation that exists between two relational
database tables when one table has a foreign key that references the primary key of the
other table. Relationships allow relational databases to split and store data in different tables
while linking disparate data items.

Relationships are of three types and the next segment talks about the same.

Types of relationships

● One to One
● One to Many
● Many to Many

Let us see what each one of them entails.

One to One – It is used to create a relationship between two tables in which a single row of
the first table can only be related to one and only one record of a second table. This
relationship tells us that a single record in Table A is related to a single record in Table B.
And vice versa.

Example – In a university, each department has only one head of the department. And one
HOD can take only one department. This shows a one-to-one (1:1) relationship between the
department and the person as a head.

One to Many – It is used to create a relationship between two tables. Any single row of the
first table can be related to one or more rows of the second table, but the rows of the second
table can only relate to the only row in the first table. It is also known as a many-to-one
relationship.

Example: of a 1:M relationship is A department that has many employees, Each employee is
assigned to one department.
Many to Many – Many to many relationships that create a relationship between two tables.
Each record of the first table can relate to any records (or no records) in the second table.
Similarly, each record of the second table can also relate to more than one record of the first
table. It also represented an N:N relationship.

Example: there are many employees involved in each project, and every employee can be
involved in more than one project.

Features of ER model

The basic E-R concepts can model most database features, some aspects of a database
may be more aptly expressed by certain extensions to the basic E-R model. The extended E-
R features are specialization, generalization, higher- and lower-level entity sets, attribute
inheritance, and aggregation.

Specialization – An entity set broken down sub-entities that are distinct in some way from
other entities in the set. For instance, a subset of entities within an entity set may have
attributes that are not shared by all the entities in the entity set. The E-R model provides a
means for representing these distinctive entity groupings.

Specialization is an “aTop-down approach” where a high-level entity is specialized into two or

more level entities.

Example – Consider an entity set vehicle, with attributes color and no. of tires. A vehicle may
be further classified as one of the following:

● Car
● Bike
● Bus

Each of these vehicle types is described by a set of attributes that includes all the attributes
of the entity set vehicle plus possibly additional attributes. For example, car entities may be
described further by the attribute gear, whereas bike entities may be described further by the
attributes automatic break. The process of designating subgroupings within an entity set is
called specialization. The specialization of vehicles allows us to distinguish among vehicles
according to whether they are cars, buses, or bikes.
Generalization
○ Generalization is like a bottom-up approach in which two or more entities of lower level
combine to form a higher level entity if they have some attributes in common.
○ In generalization, an entity of a higher level can also combine with the entities of the lower
level to form a further higher level entity.
○ Generalization is more like a subclass and superclass system, but the only difference is the
approach. Generalization uses the bottom-up approach.
○ In generalization, entities are combined to form a more generalized entity, i.e., subclasses are
combined to make a superclass.

For example, Faculty and Student entities can be generalized and create a higher level entity
Person.

Specialization
○ Specialization is a top-down approach, and it is opposite to Generalization. In specialization,
one higher level entity can be broken down into two lower level entities.
○ Specialization is used to identify the subset of an entity set that shares some distinguishing
characteristics.
○ Normally, the superclass is defined first, the subclass and its related attributes are defined
next, and relationship sets are then added.

For example: In an Employee management system, an EMPLOYEE entity can be specialized as

TESTER or DEVELOPER based on what role they play in the company.
Aggregation
In aggregation, the relation between two entities is treated as a single entity. In aggregation, the
relationship with its corresponding entities is aggregated into a higher level entity.

For example: Center entity offers the Course entity act as a single entity in the relationship which is in a
relationship with another entity visitor. In the real world, if a visitor visits a coaching center then he will
never enquiry about the Course only or just about the Center instead he will ask the enquiry about both.

Transforming ER diagrams into tables

Reduction of ER diagram to Table

The database can be represented using the notations, and these notations can be reduced to a collection
of tables.

In the database, every entity set or relationship set can be represented in tabular form.
The ER diagram is given below:

There are some points for converting the ER diagram to the table:

○ Entity type becomes a table.

In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms individual tables.

○ All single-valued attributes become a column for the table.

In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of STUDENT table.
Similarly, COURSE_NAME and COURSE_ID form the column of COURSE table and so on.

○ A key attribute of the entity type represented by the primary key.

In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID, and LECTURE_ID are the key
attributes of the entity.

○ The multivalued attribute is represented by a separate table.

In the student table, a hobby is a multivalued attribute. So it is not possible to represent multiple values in
a single column of the STUDENT table. Hence we create a table STUD_HOBBY with column name
STUDENT_ID and HOBBY. Using both columns, we create a composite key.
 ○ Composite attribute represented by components.

In the given ER diagram, student address is a composite attribute. It contains CITY, PIN, DOOR#,
STREET, and STATE. In the STUDENT table, these attributes can merge as an individual column.

○ Derived attributes are not considered in the table.

In the STUDENT table, Age is the derived attribute. It can be calculated at any point of time by calculating
the difference between current date and Date of Birth.

Using these rules, you can convert the ER diagram to tables and columns and assign the mapping
between the tables. Table structure for the given ER diagram is as below:

Object Oriented Model in DBMS

The Object-Oriented Model in DBMS or OODM is the data model where data is stored in the form of
objects. This model is used to represent real-world entities. The data and data relationship are stored
together in a single entity known as an object in the Object Oriented Model. The Object-Oriented
Database Management System is built on top of the Object Oriented Model.

We can use the Object Oriented Model in DBMS to store real-world entities. Here, we can store
pictures, audio, video, and other types of data, which was previously impossible to store with the
relational approach (Even though we can store video and audio in the relational database, it is
generally not recommended).
Example
Now let us consider an example given below.

● Here Transport, Bus, Ship, and Plane are objects.

● Bus has Road Transport as the attribute.
● Ship has Water Transport as the attribute.
● Planes have Air Transport as the attribute.
● The Transport object` is the base object and the Bus, Ship, and Plane objects derive from it.

Take a look at another example-

As you can see, here Student and Department are two different objects. Each one of them has its
attributes and methods. They are linked by a common attribute Dept_no which establishes a
relationship between objects.

Components of Object-Oriented Data Model

Components of the Object-Oriented Data Model namely objects, classes, object attributes, class
hierarchy, etc., are explained as follows- Object- It is a physical or a real-world entity. The object can
also be called the ER model entity. A single instance of an entity is defined by the object. It is known
as an 'instance of a class.

Object attribute- The objects have certain characteristics. These are known as the attributes of the
object.

Object method- The object's behavior is shown using object methods.

Class- It is a collection of similar kinds of objects. It is an entity that has attributes and methods
together.
Inheritance- It is the ability of the object within the class hierarchy to inherit the attributes and
methods of the classes above it. A new class can be derived from an existing class, the new class
has the attributes and methods described in the existing class and also has its attributes and
methods. This helps in code reusability.

comparison of Object-Oriented Data Models (OODM), Network Data Models (NDM), and
Relational Data Models (RDM)

S.N Attribute Object-Oriented Network Data Relational Data

o Data Model (OODM) Model (NDM Model (RDM)

1 Data Organizes data as Organizes data Organizes data

Structure objects with attributes as records in tables
and methods, similar connected in a (relations) with
to OOP graph-like rows (tuples) and
structure, using columns
sets (attributes)

2 Relationship Supports complex Uses pointers Uses primary

s relationships through to represent and foreign
inheritance and complex many- keys to establish
polymorphism to-many relationships
relationships between tables

3 Data Integrity High integrity with Moderate High integrity

encapsulation, integrity but due to ACID
ensuring that objects may become properties and
manage their own complex with constraints like
data manual primary keys
management of
pointers

4 Flexibility High flexibility due to Less flexible, Flexible and

reusability, difficult to easily adaptable
inheritance, and modify once due to
encapsulation established due normalized
to dependency structures and
on pointers relational rules

5 Complexity Suitable for handling Good for Effective for

Handling complex data and representing structured data;
behaviors, especially hierarchical complexity can
in applications like structures but increase with
CAD or multimedia complex in many
design and interrelated
maintenance tables

6 Ease of Use Familiar for object- Complex for Easier for users
oriented users to query familiar with SQL
 programmers, but and update due and tabular data
complex for to explicit formats
relational-oriented linkages and
database users pointers

7 Schema Modifications are Challenging; Fairly simple to

Modifications easy due to the changes often modify due to the
modular structure require independent
and encapsulation restructuring the nature of tables
entire network
structure

8 Data Low redundancy, as Moderate Low redundancy

Redundancy objects can reuse redundancy; when
inherited attributes repeated normalized, as
pointers for relations avoid
relationships duplicate data
increase
storage needs

9 Performance Efficient for complex High Good for

data operations and performance in transactional
specialized queries hierarchical data; query
(e.g., with methods in data access but optimization may
objects) slower in be required in
updating large systems
relationships

10 Query Often uses OQL Typically uses Uses SQL

Language (Object Query procedural (Structured
Language) or navigational Query
language-specific languages Language), a
queries (e.g., in C++) standardized and
widely adopted
language

11 Support for Supports transactions Limited support Strong ACID

Transactions but may lack ACID for transactions, compliance,
compliance in some often not ACID- widely used for
implementations compliant transactional
applications

12 Use Cases Ideal for complex Suitable for Widely used in

applications like hierarchical business
CAD, AI, multimedia, data models like applications,
and systems with telecommunicati ERP, CRM, and
inheritance ons and banking for
hierarchies transportation structured data