What is a Database?

There is nothing wrong with one program keeping its data in a file it owns. The trouble starts when a second program needs the same data and cannot read the first one's format, so it writes its own file. Now the same fact is stored twice, and everything below follows from that.

Redundancy

The same fact stored in several places. Wastes space, but that is the least of it — it is what makes every other problem possible.

Inconsistency

One copy updated and the others not. Nobody did anything wrong; there is simply no mechanism connecting the copies, so divergence is a matter of time.

Difficulty of access

Files have no query language and no indexes. Any question the original developer did not anticipate needs a new program written, and a full scan to answer.

Integrity problems

Rules like "balance may not go negative" live in application code, so every program must implement them, and a new program that forgets one silently corrupts the data.

Atomicity failures

A transfer is two writes that must both happen. A crash in between leaves the file half-updated, and there is no undo — the file system never knew the writes were related.

Concurrent-access anomalies

Two users read the same value, both modify it, both write back. One update is silently lost. The window is microseconds wide, so it passes every test and then happens in production.

Security problems

File permissions are all-or-nothing per file. There is no way to let payroll see salaries while the clerk sees only names, short of splitting the data — which reintroduces redundancy.

The structural move is small and everything depends on it: one program owns the stored data, and applications ask it rather than touching bytes. Because every access now passes through one place, there is finally somewhere for a query planner, a lock manager and a recovery log to live.

Database

The data itself: a shared, structured, persistent collection of related facts.

DBMS

The software managing it — MySQL, PostgreSQL, Oracle. Note that people say "database" for both, and exams do not.

Schema vs instance

The schema is the description — tables, columns, constraints — and changes rarely. The instance is the data in it right now, and changes constantly. This pair is asked about far more often than it deserves.

Data model

The kind of shapes you are allowed to describe data with: relational (tables), ER (entities and relationships), document, graph. The relational model is what this course means unless it says otherwise.

DDL and DML

DDL defines the schema (CREATE TABLE); DML manipulates the data (SELECT, INSERT, UPDATE). SQL contains both.

Metadata / data dictionary

The DBMS's own record of the schema, stored inside the database. It is why the system can answer questions about itself and check a query before running it.

A DBMS costs money in licence, in latency and in operational complexity. Files remain the right choice when the data has a single writer, no need for ad-hoc queries, and no consistency requirement across pieces — logs, configuration, media assets, scratch output. The problems above are real, but they are problems of sharing, and unshared data does not have them.