A Database Management System (DBMS) is a specialized system software designed to store, organize, retrieve, and manipulate data securely. It serves as an abstraction layer between physical storage and application programs or end-users.

File System vs DBMS

DBMS Approach

Feature	DBMS Detail
Data Redundancy	Minimized via Normalization. Changes need to be updated in only one place.
Data Abstraction	Provides 3 levels of abstraction (physical, conceptual, view). Hides physical storage paths from queries.
Concurrency	Excellent. Allows thousands of concurrent read/write operations using row-level locking.
Crash Recovery	Strong. Uses Transaction logs (WAL) to Undo uncommitted and Redo committed actions during startup.
Security	Granular. Access can be restricted down to specific tables, views, or even individual columns.

File System Approach

Feature	File System Detail
Data Redundancy	High. Same customer information is duplicated across different department files, leading to updates anomalies.
Data Abstraction	None. Application code must know the physical layout (e.g., binary offset, CSV format) of the files to read them.
Concurrency	Poor. Concurrent modifications are blocked. The operating system locks the entire file, preventing parallel updates.
Crash Recovery	Weak/None. If a crash occurs mid-write, the file gets corrupted. No built-in rollback system.
Security	Basic. Relies on OS file permissions (read/write/execute). Anyone with read permissions sees all columns.

Primary Types of DBMS Models

Database Languages

DBMS uses specialized languages to define structures, modify rows, and manage access privileges:

Language Type	Description	Key Commands & SQL Examples
DDL (Data Definition)	Defines and modifies the physical database schema and structures.	`CREATE`, `DROP`, `ALTER`, `TRUNCATE`, `RENAME` `CREATE TABLE Users (Id INT PRIMARY KEY, Name VARCHAR(50));`
DML (Data Manipulation)	Manipulates data records inside existing tables.	`INSERT`, `UPDATE`, `DELETE` `UPDATE Users SET Name = 'Alice' WHERE Id = 1;`
DQL (Data Query)	Retrieves data records from the database.	`SELECT` `SELECT * FROM Users WHERE Id = 1;`
TCL (Transaction Control)	Manages the execution flow of database transactions.	`COMMIT`, `ROLLBACK`, `SAVEPOINT` `ROLLBACK TO SAVEPOINT sv1;`
DCL (Data Control)	Grants and revokes user access permissions.	`GRANT`, `REVOKE` `GRANT SELECT ON Users TO DeveloperRole;`

DBMS Architectures

Distributed Deployments

Codd's 12 Rules for Relational Databases

Dr. E.F. Codd established 12 rules (numbered 1 through 12, plus Rule 0) that define a true Relational Database Management System (RDBMS):

Rule #	Rule Name	Description
Rule 0	Foundation Rule	The system must manage databases entirely through its relational capabilities.
Rule 1	Information Rule	All data (including metadata) must be represented as values in table columns and rows.
Rule 2	Guaranteed Access Rule	Every data item is logically accessible using table name + primary key + column name.
Rule 3	Systematic Null Treatment	Nulls must represent missing/inapplicable info in a systematic way, distinct from 0 or blank.
Rule 4	Dynamic Online Catalog	Database schema description must be stored in tables queryable using SQL.
Rule 5	Comprehensive Sublanguage	Must support a single language (like SQL) covering schema definition, manipulation, integrity, and transactions.
Rule 6	View Updating Rule	All database views that are theoretically updatable must be updatable by the system.
Rule 7	High-Level Insert/Update/Delete	Must support multi-row insert, update, and delete statements.
Rule 8	Physical Data Independence	Changes to physical storage structures (disks, file paths) must not affect application code.
Rule 9	Logical Data Independence	Changes to conceptual schemas (splitting tables, adding fields) must not impact view applications.
Rule 10	Integrity Independence	Integrity constraints (PK, FK) must be stored in catalog metadata, not embedded in application code.
Rule 11	Distribution Independence	The database must function normally even if data is moved across different physical servers.
Rule 12	Nonsubversion Rule	Low-level access routes must not bypass schema security or integrity constraints.