Introduction to Databases & DBMS

Data, Information, and Knowledge — They Are Not the Same Thing

Before we talk about databases, we need to understand what we're even storing. Most people use the words data, information, and knowledge interchangeably. In computer science — and especially in database theory — they mean very different things. Confusing them leads to bad system design.

A database stores data. A well-designed database makes it easy to extract information. A well-run business uses that information to build knowledge. This chain — data → information → knowledge — is why database design matters so deeply. A poorly designed database makes the second and third steps extremely difficult or impossible.

What Exactly Is Data?

In the context of databases, data is any known fact that can be recorded and has implicit meaning. The word "implicit" is important — the meaning exists, but it needs context to surface. The number 500 by itself is data. In the context of a salary column, it means ₹500. In the context of a distance column, it means 500 kilometres. The column name, the table, the schema — these provide the context that transforms raw data into meaningful information.

Data exists in three forms in modern systems: structured data (tables with fixed columns — the relational model), semi-structured data (JSON, XML — has some structure but flexible), and unstructured data (images, videos, PDFs — no inherent organisation). Traditional databases handle structured data. Modern systems increasingly need to handle all three — which is one reason NoSQL databases emerged.

How Data Was Stored Before Databases — And Why It Failed

To truly understand why databases were invented, you need to feel the pain of what came before. This isn't just history — these problems still exist today in organisations that rely on spreadsheets, shared drives, and ad-hoc file systems instead of proper databases.

Era 1 — Paper Records (Pre-1950s)

Banks kept ledgers. Hospitals kept patient files in metal cabinets. Factories tracked inventory in notebooks. Data was physical — paper in folders, folders in filing cabinets, filing cabinets in rooms. Finding a specific record meant physically walking to the right cabinet, finding the right folder, flipping through papers. Updating a record meant finding every copy and changing each one by hand. If a paper was lost or burned — that data was gone permanently.

Era 2 — File Systems (1950s–1970s)

When computers arrived, the obvious next step was to store data in computer files. Programs read data from flat files (text files, CSV files, binary files), processed it, and wrote results back. Each application maintained its own files. This worked for small, isolated systems — but as organisations grew and multiple applications needed to share data, a catastrophic set of problems emerged.

These problems are not hypothetical. They are the documented, real-world failures that motivated Edgar Codd, Charles Bachman, and IBM researchers to develop the relational model in the 1960s and 70s. Understanding them is not optional — they are the entire reason databases exist.

HR_System.csv:
  employee_id: E001, name: Rahul Sharma, salary: 85000, city: Bengaluru

Payroll_System.csv:
  employee_id: E001, name: Rahul Sharma, salary: 75000, city: Hyderabad

IT_Assets.csv:
  employee_id: E001, name: Rahul S.,    salary: 85000, city: Bengaluru

// Three files. Three different salaries/cities. Which is truth?
// A database would have ONE source and prevent this entirely.

SELECT name, salary, city
FROM employees
WHERE join_date > '2023-01-01'
  AND salary > 80000
  AND city = 'Bengaluru';

-- Grant analyst read access to orders table but NOT payments
GRANT SELECT ON orders TO analyst_role;
REVOKE ALL ON payments FROM analyst_role;

-- Grant manager access to see only their team's records
CREATE POLICY team_access ON employees
  USING (manager_id = current_user_id());

-- Result: same database, completely different views per role
-- No file-copying, no separate systems, fully audited

What Is a DBMS? — Every Function It Performs

A Database Management System (DBMS) is software that enables users to define, create, maintain, and control access to a database. But that definition is almost too simple. Let's be precise about what a DBMS actually does — because it does a remarkable number of things simultaneously, and understanding each function explains why databases are engineered the way they are.

Database vs DBMS vs Database System — Precise Definitions

These three terms are used interchangeably in casual conversation, but in technical contexts — and especially in exams and interviews — they have distinct meanings. Get them right.

Three-Schema Architecture — The Most Important Concept Nobody Teaches

The three-schema architecture (also called the ANSI/SPARC architecture, proposed in 1975) is the structural framework that every modern DBMS is built on. It describes how a database system separates concerns across three distinct levels — and understanding it explains nearly every major design decision in database engineering.

The central idea: different users of a database have different concerns and different views of the same data. A database architect is concerned with logical design. An application developer is concerned with the view relevant to their application. A storage engineer is concerned with physical performance. The three-schema architecture creates formal separation between these concerns so that changes at one level do not cascade to other levels.

Data Independence — Why the Three Levels Matter

The three-schema architecture delivers one major practical benefit: data independence. Data independence means that changes at a lower level do not force changes at a higher level. There are two types, and both are critically important.

Types of Database Users — Who Uses a Database and How

A database system serves many different categories of users simultaneously, each with completely different interaction styles, needs, and levels of technical depth. Understanding these user types is important because the DBMS is designed to serve all of them — and good database design means making the system work well for each one.

The Database Administrator — The Most Critical Role in Data Systems

The Database Administrator (DBA) is the person (or team) responsible for everything related to the database — its design, operation, security, performance, and recovery. In large organisations, this is a dedicated role with a specialised career path. In startups, this responsibility often falls on a senior backend engineer.

Understanding the DBA role matters for two reasons: first, it shows you the full scope of what database management actually involves (it is far more than just writing SQL). Second, many database design decisions that seem arbitrary only make sense when you understand that they exist to make the DBA's job tractable.

Types of Databases — The Full Landscape

The database landscape in 2026 is richer and more diverse than at any point in history. Understanding each type — not just what it is, but why it exists and what specific problem it solves — is essential for both engineering decisions and system design interviews.

Day 1 at a Real Company — The Database Question You'll Face

Most engineering teams have their database decisions already made when you join. But in fast-growing startups, in greenfield projects, and in senior roles — you will be part of these conversations. Here's what they actually sound like, and what knowledge makes you valuable in them.

-- User preferences: separate table, linked to users via FK
CREATE TABLE user_preferences (
  preference_id     SERIAL          PRIMARY KEY,
  user_id           INT             NOT NULL UNIQUE,  -- one row per user
  email_enabled     BOOLEAN         NOT NULL DEFAULT true,
  whatsapp_enabled  BOOLEAN         NOT NULL DEFAULT false,
  language          VARCHAR(20)     NOT NULL DEFAULT 'English'
                    CHECK (language IN ('English', 'Hindi', 'Telugu', 'Tamil', 'Kannada')),
  frequency         VARCHAR(20)     NOT NULL DEFAULT 'immediate'
                    CHECK (frequency IN ('immediate', 'daily', 'weekly')),
  updated_at        TIMESTAMP       DEFAULT CURRENT_TIMESTAMP,

  -- Link to users table. If user is deleted, preferences are deleted too.
  CONSTRAINT fk_user
    FOREIGN KEY (user_id)
    REFERENCES users(user_id)
    ON DELETE CASCADE
);

-- Index on user_id for fast lookups (already has UNIQUE index, but explicit is clear)
-- The UNIQUE constraint already creates an index — no extra index needed here.

-- To retrieve preferences for user 42:
SELECT * FROM user_preferences WHERE user_id = 42;
-- This hits the UNIQUE index — O(log n) lookup, extremely fast.

Why DBMS Appears in Every Technical Interview Regardless of Role

Students often ask: "I want to be a frontend developer — why do I need to know DBMS?" or "I'm going into DevOps — do I really need normalization?" The answer is always yes, and here's the precise reason why.

Every application, regardless of how it presents to users, ultimately reads and writes persistent data. That data lives in a database. Even if your role is one layer removed from directly writing database code, you will make architectural decisions, debug performance issues, design APIs, or review code that directly involves database concepts. Ignorance of DBMS at any seniority above junior level is a significant career limitation.

Your Complete Learning Roadmap — 20 Modules, Zero Gaps

Every module in this track is sequenced deliberately. Each one builds on the previous. You cannot understand normalization without understanding functional dependencies. You cannot understand indexes without understanding B+ trees. You cannot understand query optimization without understanding how the storage engine works. This sequence is not arbitrary — it is the order that a PhD-level database course would teach these concepts.