Computer Science · College · BCA, BTech & MCA
DBMS Architecture, Three-Schema Model & ACID Properties
Master Database Management Systems: File Systems vs DBMS, 3-Tier Architecture, ANSI-SPARC Three-Schema data independence, and ACID transaction properties.
1Why DBMS? Limitations of File Processing Systems
DBMS Architecture, Three-Schema Model & ACID Properties
Master Database Management Systems: File Systems vs DBMS, 3-Tier Architecture, ANSI-SPARC Three-Schema data independence, and ACID transaction properties.
- 1Subject — Computer Science
- 2Target Audience — BCA, BTech & MCA Students
- 3Topic Core — 3-Tier Architecture, Data Independence & Transactions
Before database systems, organizations stored records in flat OS files. ADatabase Management System (DBMS)is specialized system software designed to create, query, maintain, and administer structured databases, overcoming fundamental file processing flaws.
Traditional File System vs Modern Relational DBMS
| Parameter | Flat File Processing System | Database Management System (DBMS) |
|---|---|---|
| Data Redundancy | High — duplicate data across department files causes storage waste | Minimized via normalization and unified data models |
| Data Inconsistency | High — updating an address in one file leaves outdated records in others | Prevented — single source of truth updated atomically |
| Concurrent Access | Extremely limited — concurrent writes lead to lost updates and corruption | Robust — multi-version concurrency control (MVCC) and locking protocols |
| Data Independence | None — modifying file layout breaks application source code | High — physical and logical data independence via schema levels |
| Security & Permissions | Crude file-level OS permissions (read/write all or nothing) | Granular role-based access control (RBAC) down to row and column levels |
Data Redundancy
- Flat File Processing System
- High — duplicate data across department files causes storage waste
- Database Management System (DBMS)
- Minimized via normalization and unified data models
Data Inconsistency
- Flat File Processing System
- High — updating an address in one file leaves outdated records in others
- Database Management System (DBMS)
- Prevented — single source of truth updated atomically
Concurrent Access
- Flat File Processing System
- Extremely limited — concurrent writes lead to lost updates and corruption
- Database Management System (DBMS)
- Robust — multi-version concurrency control (MVCC) and locking protocols
Data Independence
- Flat File Processing System
- None — modifying file layout breaks application source code
- Database Management System (DBMS)
- High — physical and logical data independence via schema levels
Security & Permissions
- Flat File Processing System
- Crude file-level OS permissions (read/write all or nothing)
- Database Management System (DBMS)
- Granular role-based access control (RBAC) down to row and column levels
2Three-Schema Architecture (ANSI-SPARC Model)
The ANSI-SPARC architecture partitions the database intothree abstraction tiersto achieve completeData Independence:
1.External Schema (View Level):End-user views tailored to specific applications or roles (e.g., student portal vs accountant view).
2.Conceptual Schema (Logical Level):Global blueprint describing what data is stored and the relationships between entities (tables, columns, constraints).
3.Internal Schema (Physical Level):Low-level representation describing how data is physically persisted on disk (B-trees, hashing, indexing, record clustering).
ANSI-SPARC Data Independence Hierarchy
- 1
View 1 / View 2 (External Level)
User and application specific perspectives; hide confidential columns
- 2
Logical Data Independence
Modifying conceptual tables (adding columns) does not alter external views
- 3
Conceptual Schema
Defines entities, relations, data types, primary and foreign keys
- 4
Physical Data Independence
Modifying internal storage structures (adding B+ Tree indexes) does not alter conceptual schema
- 5
Internal Schema (Physical Level)
Direct storage blocks, byte offsets, file organization and disk allocation
3ACID Properties in Transaction Processing
Definition
Database Transaction — A logical unit of work that contains one or more database operations (READ, WRITE) that must execute reliably as a single coherent entity.
The ACID Guarantee (Detailed Breakdown with Banking Example)
| Property | Definition | Real-World Example (Transfer $500 from Account A to B) | Enforced By |
|---|---|---|---|
| Atomicity ("All or Nothing") | Either all operations of the transaction complete successfully, or the entire transaction is rolled back with zero modifications | If server crashes after deducting $500 from A before crediting B, the deduction is reversed (ABORT/ROLLBACK) | Transaction Manager & Write-Ahead Log (WAL) |
| Consistency | The database must transition from one valid state satisfying all constraints (primary keys, check constraints, foreign keys) to another | The sum of Account A and Account B balances before transfer (2,000) | DBMS Constraint Engine & Application Logic |
| Isolation | Concurrent transactions execute as if they were running in complete isolation without interfering with one another | While transfer is in-flight, a third transaction reading A’s balance sees either original 500, never intermediate corrupted state | Concurrency Control Manager (2PL / MVCC) |
| Durability | Once a transaction is committed, its changes survive permanently on non-volatile media, even through sudden power outages | After receiving "Transfer Successful" confirmation, a server reboot will not erase the newly credited $500 | Recovery Manager & Redo Log Flush |
Atomicity ("All or Nothing")
- Definition
- Either all operations of the transaction complete successfully, or the entire transaction is rolled back with zero modifications
- Real-World Example (Transfer $500 from Account A to B)
- If server crashes after deducting $500 from A before crediting B, the deduction is reversed (ABORT/ROLLBACK)
- Enforced By
- Transaction Manager & Write-Ahead Log (WAL)
Consistency
- Definition
- The database must transition from one valid state satisfying all constraints (primary keys, check constraints, foreign keys) to another
- Real-World Example (Transfer $500 from Account A to B)
- The sum of Account A and Account B balances before transfer (2,000)
- Enforced By
- DBMS Constraint Engine & Application Logic
Isolation
- Definition
- Concurrent transactions execute as if they were running in complete isolation without interfering with one another
- Real-World Example (Transfer $500 from Account A to B)
- While transfer is in-flight, a third transaction reading A’s balance sees either original 500, never intermediate corrupted state
- Enforced By
- Concurrency Control Manager (2PL / MVCC)
Durability
- Definition
- Once a transaction is committed, its changes survive permanently on non-volatile media, even through sudden power outages
- Real-World Example (Transfer $500 from Account A to B)
- After receiving "Transfer Successful" confirmation, a server reboot will not erase the newly credited $500
- Enforced By
- Recovery Manager & Redo Log Flush
Remember
- DBMS resolves file system pitfalls: eliminates redundancy, enforces consistency, and enables concurrent multi-user transactions.
- Three-schema architecture separates physical disk layouts from logical business models, guaranteeing data independence.
- ACID guarantees: Atomicity (all or nothing), Consistency (preserves constraints), Isolation (concurrent safety), Durability (survives crashes).
- WAL (Write-Ahead Logging) is the underlying mechanism enforcing Atomicity and Durability in relational database engines.
Check yourself
Question 1
Which component of a relational DBMS is primarily responsible for ensuring the Durability property of ACID transactions?Question 2
Ability to modify the internal schema (e.g. creating a secondary B+ Tree index) without affecting the conceptual schema is known as: