Introduction — Data, Databases & DBMS
In simple words
A database is where a program keeps its data in an organised way, so it can add, find, change and delete information quickly and safely. A DBMS (database management system — for example MySQL or PostgreSQL) is the software that runs the database for you. You could keep data in a plain text file, but once there is a lot of it, or many people using it at once, a file can't search fast, can't link related records, and can't protect against half-finished changes. A database fills that gap — and that is what the rest of this group is about.
What is data?
Data is raw facts on their own, with no meaning attached yet: the number 5000, the text "Alice", the date 2024-01-10. Arrange them in a structure — "user Alice has a balance of 5000 as of 2024-01-10" — and the data becomes information.
What is a database?
A database is a collection of data kept in an organised way, so that a program can:
- insert new data
- search / retrieve data quickly
- update existing data
- delete data
- link pieces of data to each other (a user has orders)
- do all of the above safely when many users act at the same time
"Database" usually means the organised data itself. The software that manages it is the DBMS.
What is a DBMS?
DBMS = Database Management System — the software that stores a database on disk and gives you a safe, fast way to work with it. It handles:
- storing and retrieving data
- keeping data consistent (rules, relationships)
- letting many users read and write at once without corrupting anything
- transactions — grouping several changes so they all happen or none do
- access control — who is allowed to see or change what
- backup and recovery
Common ones: MySQL, PostgreSQL, Oracle, SQL Server, MariaDB (relational), and Redis, MongoDB, Cassandra, DynamoDB, Neo4j (NoSQL).
Why not just use a text file?
If you keep records in a plain file, every real requirement becomes hard:
| Plain text file | Database |
|---|---|
| To find one record you scan the whole file | Indexes → find a record in a few steps |
| No links between records | Foreign keys → "this order belongs to this user" |
| Two programs writing at once corrupt the file | Concurrency control → safe simultaneous access |
| A crash mid-write leaves half-written junk | Transactions → all-or-nothing changes |
| Duplicate and inconsistent records creep in | Constraints (unique, not-null, checks) |
| No built-in backup or access rules | Backup, recovery, permissions built in |
| Slows to a crawl as the file grows | Built to stay fast at millions / billions of rows |
Every topic in this group is one of those database features, looked at closely.
Two families of database
1. Relational (SQL)
Data lives in tables (rows and columns). Tables are linked by keys. You query with SQL. Strong rules, strong consistency, powerful joins.
- MySQL — open source, very common in web apps
- PostgreSQL — open source, feature-rich, popular at product companies
- Oracle — commercial, large enterprises
- SQL Server — Microsoft's, large enterprises
- MariaDB — an open-source fork of MySQL
2. Non-relational (NoSQL)
Data is stored in a shape other than tables — chosen to spread across many machines, or to fit one specific access pattern. Four common shapes:
- Key–Value — a giant dictionary: look up a value by its key. Redis, DynamoDB.
- Document — store a whole JSON-like document per record. MongoDB, CouchDB.
- Column-family (wide-column) — rows with flexible columns, built for huge write volumes. Cassandra, HBase.
- Graph — nodes and links, built for "friends of friends" style questions. Neo4j, Neptune.
Real systems often use several databases together — a relational one for orders and payments, Redis for caching, a document store for a product catalogue. This is called polyglot persistence.
How This Connects
- Relational Model - Tables, Keys, Relationships — the next topic: how a relational database organises data into tables and links them with keys.
- SQL - Joins, Aggregations, Subqueries — the language you use to ask a relational database questions.
- Indexing - B-Tree & Hash Indexes — the "fast search" a plain file can't do.
- ACID Properties / Transactions & Isolation Levels — the "all-or-nothing changes" and "safe when many users act at once".
- NoSQL Types — the four non-relational shapes above, in detail.
- Module 4 — Data Architecture — the decisions built on this base: SQL vs NoSQL for a given system, replication, sharding, CAP.
In the Interview
You won't be asked "what is a database". But this is the base every data answer sits on:
- "Why a database and not a file or an in-memory list?" — fast search, relationships, safe concurrent writes, transactions, durability, scale.
- "SQL or NoSQL?" — in one line: relational when the data is structured with clear relationships and you need strong consistency and joins; NoSQL when you need to scale writes across many machines, the shape is flexible or changing, or there's one specific access pattern (key lookups, documents, graphs).
- "Which databases have you used?" — name a couple you actually worked with and what each was for.
Quick Revision — 6 lines
- Data = raw facts. Database = data organised so you can add / find / change / delete it fast and safely. DBMS = the software that runs it.
- A plain file has no fast search, no relationships, no safe concurrent writes, no transactions — a database adds all of that.
- Common relational: MySQL, PostgreSQL, Oracle, SQL Server. Common NoSQL: Redis, MongoDB, Cassandra, DynamoDB, Neo4j.
- Relational = tables linked by keys, queried with SQL, strong rules and consistency.
- NoSQL shapes: key–value, document, column-family, graph — each for a different scale or access pattern.
- Big systems use several databases together, each for what it does best (polyglot persistence).