DATABASE MANAGEMENT SYSTEM (copy)

Site: Muturi Pauline LMS
Course: Muturi Pauline LMS
Book: DATABASE MANAGEMENT SYSTEM (copy)
Printed by:
Date: Monday, 8 December 2025, 4:05 PM

1. Introduction to DBMS

A database management system (DBMS) is a software system for creating and managing databases. A DBMS enables end users to create, protect, read, update and delete data in a database. It also manages security, data integrity and concurrency for databases.

The most prevalent type of data management platform, the DBMS essentially serves as an interface between databases and users or application programs, ensuring that data is consistently organized and remains easily accessible.

1.1. Components of DBMS

  • Hardware − It refers to the physical machines or devices such as servers and storage systems.
  • Software − It is the set of commands or programs that controls the database.
  • Data − The information stored in the database.
  • Data Access Language − DBMS requires a language like SQL to interact with the database.
  • Users − People who interact with the database are called users. They can be database administrators, developers, and end-users.

1.2. Funtions of DBMS

  • Administration tasks. A DBMS supports many typical database administration tasks, including change management, performance monitoring and tuning, security, and backup and recovery. Most database management systems are also responsible for automated rollbacks and restarts as well as logging and auditing of activity in databases and the applications that access them.
  • Storage. A DBMS provides efficient data storage and retrieval by ensuring that data is stored in tables, rows and columns.
  • Concurrency control. In environments where multiple users access and modify the database simultaneously, a DBMS guarantees controlled transaction execution to prevent data corruption or inconsistency.
  • Centralized view. A DBMS provides a centralized view of data that multiple users can access from multiple locations in a controlled manner. A DBMS can limit what data end users see and how they view the data, providing many views of a single database schema. End users and software programs are free from having to understand where the data is physically located or on what type of storage medium it resides because the DBMS handles all requests.
  • Data manipulation. A DBMS ensures data integrity and consistency by letting users insert, update, delete and modify data inside a database.
  • Data independence. A DBMS offers both logical and physical data independence to protect users and applications from having to know where data is stored or from being concerned about changes to the physical structure of data. As long as programs use the application programming interface (API) for the database that the DBMS provides, developers won't have to modify programs just because changes have been made to the database.
  • Backup and recovery. A DBMS facilitates backup and recovery options by creating backup copies so that data can be restored to a consistent state. This protects against data loss due to hardware failures, software errors or other unforeseen events. 

1.3. Historical evolution of DBMS

1.4. Classification of DBMS

DBMS can be classified by their data model (e.g., hierarchical, network, relational, NoSQL, object-oriented), the number of users supported (single-user vs. multi-user), their distribution (centralized vs. distributed), and their purpose (e.g., operational vs. analytical). Each category represents a different way of organizing and accessing data to meet specific needs.

By data model
 
  • Hierarchical: Organizes data in a tree-like structure with parent-child relationships.
  • Network: Similar to hierarchical but allows a child to have multiple parents, creating a more flexible graph structure.
  • Relational (RDBMS): Stores data in tables with rows and columns, with relationships defined through keys.
  • Object-Oriented (OODBMS): Stores data as objects with both attributes and methods, supporting object-oriented programming principles.
  • NoSQL: A broad category for systems that manage large volumes of unstructured or semi-structured data, including document, key-value, column-family, and graph databases. 
  •  

 
By number of users
 
  • Single-user: Designed for use by only one person at a time.
  • Multi-user: Supports multiple users accessing the database concurrently. 

By distribution
 
  • Centralized: All data is stored and managed in a single physical location.
  • Distributed: Data is spread across multiple locations, which can be homogeneous (same DBMS software) or heterogeneous (different DBMS software with middleware). 

By purpose
 
  • Operational (OLTP): Optimized for day-to-day, high-volume transactions.
  • Analytical (OLAP): Designed for complex queries and data analysis, often drawing data from multiple operational systems. 

1.5. Role of key players in Database Design and Development

ROLE OF KEY PLAYERS IN DATABASE DESIGN AND DEVELOPMENT
1. Data Administrator – a business manager responsible for controlling the overall corporate
data resources
2. Database Administrator (DBA) - a technical person responsible for development of the
total system
3. Systems administrator - Oversees the database systems general operations.
4. Database administrator (DBA) - Manages the DBMS use and ensures that the database is
functioning properly. His functions include:
i. Scheme definition - The original database scheme is created by writing a set of
definitions, which are translated by DDL compiler to a set of tables that are
permanently stored in the data dictionary.
ii. Storage structure and Access Methods Definitions - By writing a set of definitions for
appropriate storage structures and access methods, which are translated by the data
storage and definition language compiler.
iii. Scheme and physical organisation modifications - Modification to either the database
schema or description of the physical storage organisation are accompanied by
writing a set of definitions which are used by either the DDL compiler or the data
storage and definition language compiler to generate modification to appropriate
internal systems tables e.g. data dictionary.
iv. Granting authorization to data access - This is so as to regulate which parts of the
database users can access.
v. The database manager keeps integrity Constrains in a special system structure
whenever an update takes place in the system.
5. Database designers - These are the database architects who design the database structure.
6. Systems Analysts & Programmers (application programmers) - They design and
implement the application programs they design & create the data entry scheme, reports &
procedures through which users access and manipulate the databases data.
7. End users - These are the people who use the application programs to run the
organizations daily operations.

2. Database Organization

Database organization is

the structure and format of data within a database, determining how user attributes are arranged in tables and other topological structures. Common types include the flat, hierarchical, relational, and object-oriented models

2.1. Types of Database Organization

  • Flat: A simple format with a single record type and fixed fields, which can lead to data repetition and potential errors.
  • Hierarchical: Organizes data in a tree-like structure with parent-child relationships. This can make some queries easy but others difficult, and it may not work well for complex relationships.
  • Relational: Stores data in logically independent tables that can be joined together. This is a common model that uses rows and columns for efficient processing and retrieval.
  • Object-oriented: Models data as objects, which is another approach to representing real-world information. 

3. Principles and Techniques of Database Design

Principles of database design

 
  • Data Integrity: Ensuring data is accurate, consistent, and reliable by preventing duplicates and establishing relationships between tables.
  • Normalization: Organizing data into tables to reduce redundancy and minimize data anomalies that can occur during insertions, updates, or deletions.
  • Scalability: Designing the database to handle future growth in data volume and user numbers without compromising performance or integrity.
  • Performance: Structuring the database for fast query and data retrieval. This is achieved through techniques like proper indexing and efficient data modeling.
  • Security: Implementing measures to protect sensitive data from unauthorized access and breaches.
  • Flexibility and Maintainability: Creating a design that is easy to update, modify, and extend in the future. This includes using consistent naming conventions and good documentation

3.1. Techniques in database design

 
  • Requirements Gathering: The first step is to clearly understand the purpose of the database and the data it needs to store.
  • Entity-Relationship Modeling: Creating a visual blueprint that represents the data and the relationships between different data entities.
  • Normalization: A systematic process for organizing data into tables to reduce redundancy and dependency, often involving a series of normal forms (e.g., 1NF, 2NF, 3NF).
  • Denormalization: Intentionally introducing redundancy to improve read performance in specific cases, such as in data warehousing.
  • Indexing: Creating data structures that speed up data retrieval by allowing the database to find rows that match specific criteria more quickly.
  • Data Types: Choosing the most appropriate and efficient data type for each column (e.g., INT, VARCHAR, DATE) to minimize storage and improve performance.
  • Constraints: Applying rules to enforce data integrity, such as primary keys, foreign keys, UNIQUE constraints, and NOT NULL constraints.
  • Naming Conventions: Establishing and following consistent and clear naming conventions for tables, columns, and other objects to improve readability and maintainability.
  • Stored Procedures and Views: Using these to encapsulate logic, improve security, and simplify complex queries.
  • Documentation: Creating and maintaining documentation of the database design for future reference and maintenance

3.2. Database Design Life Cycle