F200 TA1: Understanding Data
What data actually is, how it differs from information and knowledge, the types it comes in, and the formats it is stored in.
Data, information, knowledge and wisdom
These four words are used loosely in conversation and precisely in this unit. The difference is what has been added at each stage.
| Term | What it is | Example |
|---|---|---|
| Data | Raw facts and figures, with no context | 37.2, A1402, 2026-03-14 |
| Information | Data given context and structure, so it means something | "Patient A1402's temperature was 37.2 °C on 14 March 2026" |
| Knowledge | Information combined with experience and interpretation | "That reading is within the normal range for this patient" |
| Wisdom | Knowledge applied to make a judgement about what to do | "No action needed, but review if it rises for three consecutive days" |
Each step upward adds something and loses something. Data is precise and useless on its own. Wisdom is useful and cannot be stored in a database.
Why this matters in practice
An organisation that collects data and never turns it into information has spent money on storage and gained nothing. The whole point of an analytics pipeline is to move left to right across that table, and most of the technical work is in the first two steps.
A question asking for the difference between data and information wants the word context. Data on its own carries no meaning; information is data that has been given structure, units, labels and a reference point.
Types and classifications of data
Quantitative and qualitative
- Quantitative data is numerical: counts, measurements, amounts. It can be calculated with.
- Qualitative data is descriptive: words, categories, opinions, images. It can be counted and grouped but not averaged.
Discrete and continuous
- Discrete values can only take particular values, usually whole numbers: the number of students in a class, the number of orders.
- Continuous values can take any value in a range, limited only by the precision of measurement: height, temperature, time taken.
Levels of measurement
| Level | What it allows | Example |
|---|---|---|
| Nominal | Named categories with no order | Payment method, country, colour |
| Ordinal | Ordered categories with uneven gaps | Satisfaction: poor, fair, good, excellent |
| Interval | Ordered with equal gaps, no true zero | Temperature in °C, calendar years |
| Ratio | Ordered, equal gaps, a true zero | Height, weight, income, duration |
The level decides which calculations are legitimate. A mean of nominal data is meaningless. A mean of ordinal data is common and technically dubious: the gap between "poor" and "fair" is not the gap between "good" and "excellent".
Structure
| Structure | What it means | Examples |
|---|---|---|
| Structured | Fits a fixed schema of rows and columns | Relational database tables, CSV files, spreadsheets |
| Semi-structured | Has tags or markers but no fixed schema | JSON, XML, email, log files |
| Unstructured | No predefined model at all | Free text, images, audio, video, documents |
Most of the data an organisation holds is unstructured, and most of the data it actually analyses is structured. Closing that gap is a large part of what data engineering is.
Other distinctions worth the vocabulary
- Primary data: collected by you, for this purpose. Secondary data: collected by somebody else for theirs.
- Internal data: generated by the organisation. External data: bought, licensed or taken from open sources.
- Metadata: data about data. The file size, the capture time, the camera, the column types, the author, the schema.
- Open data: published for anyone to use, often by government, usually under a permissive licence.
Data file formats
The format decides what can be stored, how large the file is, and what can read it.
| Format | Structure | Good at | Weak at |
|---|---|---|---|
| CSV | Structured, plain text | Universally readable, tiny, simple | No types, no nesting, breaks on commas in fields |
| TSV | Structured, plain text | As CSV, safer with commas | Same limitations otherwise |
| JSON | Semi-structured | Nesting, APIs, mixed types, human readable | Verbose, slow to parse at scale |
| XML | Semi-structured | Schemas, validation, long-lived documents | Very verbose |
| XLSX | Structured | Formulas, formatting, multiple sheets | Proprietary, size limits, easy to corrupt by hand |
| SQL / database | Structured | Relationships, integrity, concurrent access, querying | Needs a server and a schema |
| Parquet | Structured, columnar, binary | Compressed, fast on huge analytic queries | Not human readable, needs tooling |
| TXT | Unstructured | Anything | Nothing is guaranteed |
| Unstructured for data purposes | Fixed presentation | Extracting data from it is painful and error prone |
Row stores and column stores
A row-oriented file or table keeps each record together, which suits writing one order at a time and reading whole records. A column-oriented format such as Parquet keeps each field together, which suits reading one column across ten million records. If the question is "what is the average order value this year", a columnar format reads one column instead of every field of every row, and that is why analytic warehouses are built that way.
Choosing a format
- Sharing a small table with anyone: CSV
- An API response, or anything nested: JSON
- A document that must validate against a schema: XML
- A finished model with formulas for a human to use: XLSX
- Many related entities, many users, guaranteed integrity: a database
- Hundreds of millions of rows to analyse: Parquet in a data lake
A CSV has no idea whether 0123 is a number or a product code, or whether 03/04/2026 is March or April. Every CSV import needs the types declared, and leading zeros and dates are where real analyses silently go wrong.
Key terms you must be able to define
- Data
- Raw facts and figures with no context attached.
- Information
- Data given context and structure so that it carries meaning.
- Knowledge
- Information combined with experience and interpretation.
- Quantitative data
- Numerical data that can be calculated with.
- Qualitative data
- Descriptive, non-numerical data such as words, categories or images.
- Discrete data
- Data that can take only particular values, usually whole numbers.
- Continuous data
- Data that can take any value within a range.
- Nominal data
- Named categories with no inherent order.
- Ordinal data
- Ordered categories where the gaps between them are not equal.
- Structured data
- Data that fits a fixed schema of rows and columns.
- Semi-structured data
- Data with tags or markers but no fixed schema, such as JSON or XML.
- Unstructured data
- Data with no predefined model, such as free text, images or video.
- Metadata
- Data about data: its size, origin, structure, author or capture time.
- Open data
- Data published for anyone to use, usually under a permissive licence.
Flashcards
Say the definition out loud before you flip the card. Retrieving it from memory is what builds recall, reading it again is not.
Reach the top grade on this topic
The marks at Level 3 are in precision of vocabulary and consequence. Not "JSON is good for APIs" but "JSON is used for API responses because it supports nesting, so a single response can carry an order and its line items together, which a flat CSV cannot represent without repeating the order header on every row."
Mistakes that cost marks here
- Using 'data' and 'information' interchangeably. The difference is context, and it is examined.
- Calling a spreadsheet unstructured. It has rows, columns and a schema, so it is structured.
- Averaging ordinal data, such as treating satisfaction ratings as numbers, without acknowledging the problem.
- Forgetting that CSV carries no type information, which is where leading zeros and dates break.
- Confusing metadata with the data itself.
- Assuming unstructured data is unusable. Most organisational data is unstructured.
A supermarket's loyalty scheme once worked out that a customer was pregnant before her family knew, purely from a change in which unscented products she bought. No single purchase said anything. The pattern across all of them did.
Knowledge check
Exam-style questions
Five written questions in the style of the real paper. Write a full answer, then let the marker check it against the mark scheme.
- LStructured data fits a fixed schema of rows and columns
- LUnstructured data has no predefined model, with an example
Structured data fits a fixed schema of rows and columns, such as a database table, whereas unstructured data has no predefined data model at all, such as free text, images or video.
- LData defined as raw facts without context
- LInformation defined as data given context
- LKnowledge defined as information plus experience or interpretation
- LA single example carried through all three
Data is a raw fact with no context attached: the value 37.2 on its own says nothing, because it could be a temperature, a price or a percentage. Information is that data given context and structure, so 'patient A1402's temperature was 37.2 degrees Celsius on 14 March' now means something, because it has a subject, a unit and a time. Knowledge is that information combined with experience and interpretation: a clinician knows that 37.2 is within the normal range for an adult, which is a judgement the database itself cannot hold. Each step adds something the previous one lacked, and the whole purpose of an analytics process is to move from the first to the third.
- LCSV is readable by every tool without special software
- LIt is small and simple to produce
- LRisk: no type information
- LThe consequence of that risk
- LRisk: no nesting, or delimiter collisions
- LA mitigation is offered
CSV is a reasonable choice here because all three consumers can read plain text without any shared library or licence: the spreadsheet opens it directly, the reporting tool imports it, and the Python script reads it in two lines. The files are small, trivial to generate from a database query and easy for a human to inspect when something looks wrong, which matters for a daily operational export. The first risk is that CSV carries no type information, so every consumer guesses: a product code of 0123 is read as the number 123, and a date written 03/04/2026 is March in one tool and April in another, and both failures are silent. The second risk is that the format is flat and delimited, so a product description containing a comma breaks the row alignment unless fields are properly quoted, and nested data such as an order with several line items has to be flattened by repeating the order header. Both risks are manageable: publish a data dictionary declaring each column's type and format, use ISO dates, quote all text fields, and move to Parquet or a database export if the volumes grow.
- LUnstructured data has no schema to query
- LIt must be processed before analysis
- LVolume is a problem
- LStorage and cost implications
- LQuality and consistency problems
- LLegal or privacy problems specific to this data
- LA realistic approach is proposed
- LA judgement weighing value against cost
The first problem is that unstructured data cannot be queried. A relational table can be aggregated with a single statement, whereas a folder of support emails has no fields, so there is nothing to group by and nothing to sum. Anything useful has to be created first, by extracting entities, classifying each message by topic and sentiment, transcribing recorded calls and attaching metadata, and all of that is a processing pipeline that has to be built, tuned and maintained rather than bought. The second problem is scale: unstructured content is the majority of what most organisations hold, and it is large per item, so storing it in a form that can be reprocessed means a data lake and the cloud costs that go with it. Quality is the third problem and the most underestimated. Free text is inconsistent by nature: the same product is spelled four ways, the same complaint is phrased differently by every customer, and sarcasm defeats sentiment analysis, so any measure derived from it carries error that is hard to quantify. Fourth, this data is legally the most dangerous the organisation holds. Support emails contain personal data the customer volunteered, sometimes including health information, which is special category data under the UK GDPR; it was collected to answer a query, not to train a model, so reusing it for analytics engages purpose limitation, and retention schedules are almost never applied to mailboxes. A workable approach is therefore narrow rather than total: pick one question worth answering, such as which product generates the most support contact, sample rather than process everything, classify that sample with a tested model, and keep a human check on the output. Judged overall, unstructured data is worth the effort only when a specific decision depends on it, because the cost of making it analysable is paid up front and in full, while the value is speculative until the first question has actually been answered.