BIT202 Database Management System

Database Management SystemUnit 17 min read

DBMS Basics: Systems, Users, and Architecture

Unit 1 of Database Management System: Explores core concepts of DBMS—definitions, user roles, architecture (three-schema), advantages over file systems, and real-world applications like eSewa and NEPSE.

TAKEAWAYS:

  • A DBMS is software that manages data storage, retrieval, and security for applications (e.g., eSewa transactions).
  • The three-schema architecture separates data into external (user view), conceptual (logical design), and internal (physical storage) layers.
  • Logical independence lets schema changes without altering user queries; physical independence hides storage details from users.
  • Database users range from administrators (full control) to casual users (read-only access), each with distinct privileges.
  • DBMS offers scalability, security, and concurrency but requires higher maintenance than file systems.
  • Real-world examples: NEPSE uses DBMS for stock market data; Daraz relies on it for inventory and orders.

1. What is a Database Management System (DBMS)?

A DBMS is a system software that facilitates the creation, storage, retrieval, and management of databases. It acts as an intermediary between the database (data storage) and applications (e.g., eSewa, Daraz) that use the data.

Key Characteristics of DBMS

  • Centralized Data Storage: Data is stored in a structured format (e.g., tables in relational DBMS).
  • Controlled Access: Users interact via queries (e.g., SQL) rather than direct file manipulation.
  • Data Integrity: Ensures consistency (e.g., preventing duplicate student records in a university DB).
  • Concurrency: Allows multiple users to access data simultaneously (e.g., Ncell customers checking balances).
  • Security: Implements authentication (e.g., login credentials for NEPSE accounts).

DBMS vs. File-Based Systems

Feature DBMS File-Based System
Data Redundancy Minimal (data shared) High (copies in multiple files)
Data Integrity Enforced (e.g., constraints) Manual (prone to errors)
Concurrency Supported (locks, transactions) Not supported
Security Role-based access control Limited (file permissions)
Scalability High (handles large datasets) Low (bottlenecks at scale)

Example: Compare a university’s student records managed via Excel (file-based) vs. a DBMS like MySQL. The DBMS ensures no duplicate IDs and allows professors to query grades without errors.


2. Types of Database Users

Users interact with a DBMS at different levels, each with specific privileges:

stateDiagram-v2
    [*] --> User
    User --> Admin: Full control (create tables, grant access)
    User --> DBA: Manages DB structure (schema changes)
    User --> Application: Executes queries (e.g., Daraz’s order system)
    User --> Casual: Read-only access (e.g., Ncell customer viewing bills)
    User --> Auditor: Monitors compliance (e.g., NEPSE regulatory checks)

Worked Example:

  • DBA (Database Administrator): At NEPSE, the DBA ensures the stock market database schema evolves with new regulations (e.g., adding IPO tracking fields).
  • Casual User: A Pathao rider checks their earnings via a read-only dashboard (no ability to alter data).

3. Three-Schema Architecture

A DBMS separates data into three independent schemas to achieve data independence:

graph TD
    A["External Schema\n(User View)"] -->|"Maps to"| B["Conceptual Schema\n(Logical Design)"]
    B -->|"Maps to"| C["Internal Schema\n(Physical Storage)"]
    A -->|"Query"| B
    B -->|"Query"| C

Definitions

  • External Schema: Customized view for each user group (e.g., a professor sees only their students’ grades).
  • Conceptual Schema: Unified logical design (e.g., Student(SID, Name, Grade) table).
  • Internal Schema: Physical storage details (e.g., file formats, indexing).

Data Independence

Type Description Example
Logical Changes to conceptual schema don’t affect external views. Adding a Department field to Student doesn’t break professor queries.
Physical Changes to internal schema (e.g., storage engine) don’t affect users. Switching from MySQL to PostgreSQL without altering SQL queries.

Why It Matters:

  • eSewa uses DBMS to hide payment processing logic (internal schema) from users, who only see transaction success/failure (external schema).

4. Advantages of DBMS

  1. Data Integrity: Constraints (e.g., PRIMARY KEY) prevent invalid data (e.g., negative salary in a bank DB).
  2. Concurrency Control: Locks ensure transactions don’t corrupt data (e.g., two Pathao drivers updating the same route simultaneously).
  3. Security: Role-based access (e.g., NEPSE traders can’t alter market rules).
  4. Scalability: Handles growth (e.g., Daraz’s DB scales with seasonal sales spikes).
  5. Backup and Recovery: Shadow paging (Unit 8) restores data after crashes.
  6. Reporting: Aggregates data (e.g., Ncell’s monthly revenue reports).

Disadvantages:

  • Complexity: Requires DBAs to manage schemas.
  • Cost: Licensing (e.g., Oracle) and maintenance overhead.
  • Performance Overhead: Indexing and transactions slow down simple queries.

5. Real-World Applications

In the Real World

  1. eSewa:

    • Idea: Three-schema architecture separates user views (e.g., merchant dashboard) from the underlying transaction logs (internal schema).
    • How: A merchant sees only their sales data (external schema), while eSewa’s DBMS stores raw transactions (internal schema) for audits.
  2. NEPSE (Nepal Stock Exchange):

    • Idea: Concurrency control prevents race conditions when multiple traders place bids simultaneously.
    • How: DBMS locks the Stock table during a trade to avoid double-selling shares.
  3. Daraz:

    • Idea: Database users include:
      • DBA: Manages the Order and Inventory tables.
      • Casual User: Views order status via the app (read-only).
    • Worked Example: During Diwali sales, Daraz’s DBMS auto-scales storage (physical independence) while users see consistent product availability (logical independence).

6. Database Recovery (Preview for Unit 8)

Shadow Paging: A recovery technique where a copy (shadow) of the database is maintained alongside the live version. When data is updated, changes are logged in the shadow, which can be swapped back if the primary DB fails.

Primary Page Shadow Page
Data (v1) Data (v1)
(Updated) (Backup)
When the primary page crashes, the shadow page restores the last known good state.

Example: If Ncell’s billing system crashes mid-night, shadow paging reverts to the last saved state (e.g., before 2 AM), minimizing lost revenue.


7. Exam Tip

  • Focus on Definitions: Memorize key terms like DBMS, three-schema architecture, logical vs. physical independence, and database users.
  • Diagrams: Always draw the three-schema architecture and shadow paging for full marks.
  • Real-World Links: Connect concepts to Nepali apps (eSewa, NEPSE) or global examples (Google Search DBMS).
  • SQL Practice: Expect CREATE TABLE and INSERT questions (e.g., from past TU exams).
  • Comparison Tables: Highlight DBMS vs. file systems, or logical vs. physical independence, as shown above.
  • Avoid: Descriptive answers without examples. Use Nepali context (e.g., "How would a bank use DBMS for loan processing?").

Based on the TU BIT syllabus for Database Management System (BIT202), unit 1.

Discussion

Loading…