Database Concepts & The Need for DBMS

Introduction

This unit moves from Python into a different way of working with data — one built specifically to store, organise, and retrieve large amounts of it reliably. That's what a database is for.

Concept

A database is an organised collection of related data, stored so it can be efficiently accessed, managed, and updated. A Database Management System (DBMS) is the software that actually creates, maintains, and controls access to a database.

Storing data in plain files (like a spreadsheet per class) instead of a real database creates real problems at scale:

• Data Redundancy — the same data repeated in multiple places, wasting space and risking inconsistency.
• Data Inconsistency — the same fact stored in two places disagreeing after only one copy gets updated.
• Difficulty in Data Access — no organised way to search or filter large amounts of data quickly.
• Lack of Data Integrity & Security — no built-in way to enforce rules on data, or control who can access it.

A DBMS exists specifically to solve all four.

Explanation

Redundancy and inconsistency are closely linked, not two unrelated problems: redundancy (the same fact stored twice) is exactly what makes inconsistency possible in the first place — if a student's address is stored in only one place, it can never disagree with itself; stored in three separate files, updating only one of them creates exactly that disagreement.

Note: A DBMS doesn't just store data — it actively manages it: enforcing rules, controlling access, and keeping data consistent, none of which a plain file on its own does automatically.

Summary

A database is an organised collection of related data; a DBMS is the software managing it. Storing data in plain files instead risks redundancy, inconsistency, difficult access, and weak integrity/security — the exact four problems a DBMS is built to solve.

Why we moved away from File Systems

In the early days of computing, data was stored in simple flat files (like Text or CSV files). However, as data grew, several major problems emerged. These problems are exactly what a Database solves.

Key Functions of a DBMS:

Introduction

The most widely used way to organise a database is the relational model — the one this entire unit's SQL chapter is built on. This topic names its core vocabulary.

Concept

In the Relational Model, data is organised into tables (also called relations). CBSE's precise terminology:

• Table (Relation) — a two-dimensional grid of rows and columns holding one kind of data (e.g., a STUDENT table).
• Row (Tuple) — one single record — one student's complete set of data.
• Column (Attribute / Field) — one specific property shared by every row (e.g., Name, Marks).
• Domain — the set of all valid values a specific column is allowed to hold (a Marks column's domain might be whole numbers from 0 to 100).
• Degree — the number of columns (attributes) in a table.
• Cardinality — the number of rows (tuples) in a table.

Worked Example

A STUDENT table:

This table has a Degree of 3 (three columns: RollNo, Name, Marks) and a Cardinality of 3 (three rows). Each row is one Tuple — Aisha's entire record is one Tuple. Name is one Attribute.

Note: CBSE exams frequently ask for Degree and Cardinality directly from a shown table — Degree counts columns, Cardinality counts rows. Mixing the two up is a common, easily-avoided mistake.

Explanation

Every one of these terms has an everyday synonym (Table/Relation, Row/Tuple, Column/Attribute) — CBSE uses both interchangeably, so recognise either name for the same thing, since a question may use either term for the same concept.

Summary

The Relational Model organises data into Tables (Relations), made of Rows (Tuples) and Columns (Attributes/Fields). A column's Domain is its set of valid values; a table's Degree is its column count, and its Cardinality is its row count.

The Anatomy of a Relation

While we commonly use terms like "Rows" and "Columns," the technical relational model uses specific scientific terms that appear in exams:

Introduction

The STUDENT table from the last topic needs a reliable way to identify one exact row out of many. This topic covers the keys that do that.

Concept

• Candidate Key — any column (or minimal combination of columns) that can, on its own, uniquely identify every row in a table. A table can have more than one Candidate Key.
• Primary Key — the one Candidate Key actually chosen to uniquely identify rows in practice. It can never be NULL (empty), and its value must never repeat.
• Alternate Key — every Candidate Key that was not chosen as the Primary Key.

Worked Example

In the STUDENT table (RollNo, Name, Marks), suppose both RollNo and an Email column (not shown above, but imagine it added) could each uniquely identify a student. Both RollNo and Email are Candidate Keys. If RollNo is chosen to actually enforce uniqueness, it becomes the Primary Key, and Email — still a valid Candidate Key, just not the chosen one — becomes an Alternate Key.

Note: Every Primary Key is also a Candidate Key (it was chosen from the candidates) — but not every Candidate Key is a Primary Key, since only one candidate can be chosen.

Explanation

The relationship between these three terms is really about narrowing down: Candidate Key is the broad category of "anything that could uniquely identify a row"; Primary Key is the one specific choice actually enforced; Alternate Key is simply "candidate, but not the chosen one" — three labels for three positions in the same one decision, not three unrelated concepts.

Summary

A Candidate Key is any column (or combination) that could uniquely identify a row; the Primary Key is the one Candidate Key actually chosen, and can never be NULL or repeat; every other Candidate Key becomes an Alternate Key.

Types of Relational Keys

There is a specific relationship between Candidate, Primary, and Alternate keys. Think of it as a selection process for a sports team: many are eligible, but only one is chosen as the captain.