From data to information
Data is raw, unprocessed facts: 21, Ali, 72. It has no meaning until someone says what the numbers are. Information is data with that context supplied — roll number 21, named Ali, scored 72 in physics. Knowledge is what you can then do with it: Ali is in the top quarter of the class and needs no extra support.
Everything in this chapter and the next six exists to move data along that chain reliably, for many users, without losing any of it.
| Term | Meaning |
|---|---|
| Field | one item of data — a name, a mark, a date |
| Record | all the fields describing one thing — one student |
| File / table | a collection of records of the same type |
| Database | a set of related tables, managed together |
| Entity | a real thing the database stores data about |
| Attribute | a property of an entity — its fields |
Data types, and choosing them properly
Every field has a data type, which decides what may be stored, how much space it takes, and what operations are allowed. Choosing well is not fussiness — a badly chosen type either rejects valid data or accepts nonsense.
The rule of thumb: store a value as a number only if you will do arithmetic on it. A phone number is text, despite consisting of digits, because you never add two phone numbers and because a leading zero would be lost.
| Type | Holds | Use for |
|---|---|---|
| Text / varchar | characters | names, addresses, phone numbers |
| Integer | whole numbers | quantities, marks, counts |
| Decimal / real | fractional numbers | prices, measurements, averages |
| Date / time | calendar values | birth dates, timestamps |
| Boolean | true or false | present/absent, paid/unpaid |
| Currency | money to fixed precision | fees, salaries |
Why a phone number is not a number
Stored as a number, 0300 1234567 loses its leading zero, cannot hold a dash or a space, and might silently be rounded. Stored as text it keeps every character exactly. The test is always the same: if you would never do arithmetic on it, it is text — which also covers roll numbers, product codes and national identity numbers.
Why flat files were abandoned
Before databases, each program kept its own file. The library kept a student file, the examinations office kept another, the accounts office a third. That arrangement produces five specific problems, and the syllabus expects them by name.
- Data redundancy — the same student's address stored in three files.
- Data inconsistency — the address is updated in one file and not the others, so the system now holds two different answers and no way to tell which is right.
- Data dependence — each program contains the file's layout, so adding a field means editing every program that reads it.
- Poor sharing and security — access is all or nothing at the file level; you cannot let the library see names but not marks.
- Difficult ad-hoc queries — answering a question nobody anticipated means writing a new program.
Inconsistency is the one that really hurts
Redundancy wastes space, which is cheap. Inconsistency destroys trust: once two files disagree about an address, nobody can tell which is correct without going back to the student, and every report drawn from either is suspect. A database stores each fact once, so the question cannot arise — and that, rather than saving disk space, is the argument for it.
What a database gives you instead
A database stores related data once, in a structured form, managed by software that every program goes through rather than around. That single change addresses all five problems.
Each fact is stored in one place, so there is nothing to become inconsistent. Programs ask the management software for data rather than reading a file layout, so the structure can change without rewriting them. Permissions are set per user and per table. And a query language answers new questions without new programs.
A school keeps student details in the library system, the examination system and the fee system as three separate files. A student moves house. Explain what goes wrong and how a database prevents it.
- The address must be changed in three places, by three different people.Nothing connects the three files, so nothing propagates a change.
- If one is missed, the system holds two different addresses — data inconsistency.This is not a hypothetical: in practice at least one always is missed.
- Fee reminders now go to the old address while examination results go to the new one, and neither office knows the other disagrees.The consequence is invisible until something goes wrong for the student.
- In a database the address is stored once in the STUDENT table, and all three systems read that one record.One update, and every system sees it immediately.
- The fact is stored once, so there is no second copy to disagree with.This is what "eliminating redundancy" is actually for.
Three copies mean three updates and at least one missed — inconsistency. A database stores the address once.
Before you leave this chapter
- Field → record → table → database. An entity is the real thing; attributes are its fields.
- Store as a number only what you would do arithmetic on. Phone numbers are text.
- Flat files cause redundancy, inconsistency, data dependence, poor security and difficult queries.
- Inconsistency is the serious one — it destroys trust in every report.
- A database stores each fact once and mediates all access through management software.