Data Analytics F200 Paper D: Fundamentals of Data Analytics
A full length F200 paper built around a bus company's journey data: types and levels of data, data quality in an extract, averages and percentage change, ETL, interoperability, access control, the data protection principles and rights, the roles, and a 10 mark discussion of redesigning timetables.
Instructions
- Time allowed
- 1 hour 15 minutes
- Total marks
- 60
- Calculator
- A calculator may be used.
- Answer all the questions.
- The number of marks for each question is shown in brackets. Use it as a guide to how much to write.
- The clock at the top counts down from the real time allowed. When it reaches zero the paper is locked and marked, as it would be collected in the exam hall.
- The 10 mark question is an extended response. In the real exam it is marked in levels; here every relevant point you make earns a mark, up to 10.
- Use the resource material: the marks are for what is in the extract, not for general statements about data. Show your working in calculations.
Questions
Answer every question, then finish the paper to have it marked. Marking as you go teaches you far less.
| Nominal | Ordinal | Interval | Ratio | |
|---|---|---|---|---|
| The route number a passenger travelled on | ||||
| A satisfaction rating: poor, fair, good or excellent | ||||
| The temperature inside the bus in °C | ||||
| The journey time in minutes |
Tick one box in each row.
- LThe route number a passenger travelled on: Nominal
- LA satisfaction rating: poor, fair, good or excellent: Ordinal
- LThe temperature inside the bus in °C: Interval
- LThe journey time in minutes: Ratio
A route number is a label with no order, so it is nominal. Ratings are ordered with uneven gaps, ordinal. Celsius has equal gaps but no true zero, interval. Time has a true zero, ratio.
| Structured | Semi-structured | Unstructured | |
|---|---|---|---|
| A table of ticket sales with fixed columns | |||
| A JSON feed of bus locations from an API | |||
| CCTV video recorded on the buses | |||
| Passengers' complaints, typed as free text |
Tick one box in each row.
- L1 mark for both: A table of ticket sales with fixed columns: Structured; A JSON feed of bus locations from an API: Semi-structured
- L1 mark for both: CCTV video recorded on the buses: Unstructured; Passengers' complaints, typed as free text: Unstructured
Fixed columns are structured, JSON has tags but no fixed schema, and video and free text have no model at all.
Tick one box.
- LD JSON
JSON holds nested, labelled data without a fixed schema, which is why APIs use it.
- Lmetadata
Metadata.
Figure 1: an extract from Coastline Buses' journey records
| JourneyID | Date | Route | Boarding stop | Fare (£) | Journey time (min) |
|---|---|---|---|---|---|
| 1043 | 2026-03-02 | 7 | Harbour Street | 2.00 | 24 |
| 1044 | 2026-03-02 | 7 | Bus Station | 2.00 | 22 |
| 1045 | 2026-03-02 | 12 | Castle Road | 1.50 | 18 |
| 1045 | 2026-03-02 | 12 | Castle Road | 1.50 | 18 |
| 1046 | 31/02/2026 | 7 | Harbour Street | 25 | |
| 1047 | 2026-03-03 | 7 | Bus Station | 2.00 | 900 |
| Accuracy | Completeness | Uniqueness | Validity | |
|---|---|---|---|---|
| Journey 1045 is recorded twice | ||||
| Journey 1046 has no fare | ||||
| Journey 1046 is dated 31/02/2026 | ||||
| Journey 1047 took 900 minutes on a route that takes about 25 |
Tick one box in each row.
- LJourney 1045 is recorded twice: Uniqueness
- LJourney 1046 has no fare: Completeness
- LJourney 1046 is dated 31/02/2026: Validity
- LJourney 1047 took 900 minutes on a route that takes about 25: Accuracy
A repeated record breaks uniqueness, a blank field completeness, an impossible date validity, and a value that cannot match reality accuracy.
- LValidation is an automatic check that data is sensible and follows the rules, when it is entered
- LExample of validation: a range check on journey time, or a format check on the date
- LVerification checks that data matches the source it was copied from, that it was entered correctly
- LExample of verification: double entry, or checking against the ticket machine's record
Validation is an automatic check that data is reasonable and follows the rules: a range check would reject a journey time of 900 minutes on route 7, and a format check would reject 31/02/2026. Validation cannot tell whether sensible data is correct. Verification checks that data matches its source, for example by entering it twice and comparing, or by checking a record against the ticket machine's own log, so a mistyped fare of 2.50 instead of 2.00 would be caught.
- L24.6 min
- L25 min
- L25 min
- L12 min
Mean: 172 / 7 = 24.6. In order the times are 19, 22, 24, 25, 25, 26, 31, so the median, the middle value, is 25. The mode, the most common, is 25. The range is 31 - 19 = 12.
- LThe median is not affected by extreme values (outliers)
- Lsuch as one journey delayed by a breakdown, which would pull the mean up
One journey held up by a breakdown or an accident could take an hour and pull the mean up, making every journey look slower. The median is the middle value, so a single extreme journey barely moves it.
- LCorrect answer, full marks: 12.5 %
- LMethod: Works out the increase, 6,000, and divides it by 48,000
54,000 - 48,000 = 6,000. 6,000 / 48,000 = 0.125. 0.125 x 100 = 12.5%.
- LCorrelation does not prove causation
- LA third factor, such as summer tourists or school holidays, could increase both
Correlation does not show causation. Both figures are probably driven by a third factor, such as tourists in the summer, who both take more buses and buy more from the café.
| Extract | Transform | Load | |
|---|---|---|---|
| Data is copied out of the ticket machines' database | |||
| Dates are converted to one format and duplicates are removed | |||
| The cleaned data is written into the data warehouse |
Tick one box in each row.
- LData is copied out of the ticket machines' database: Extract
- LDates are converted to one format and duplicates are removed: Transform
- LThe cleaned data is written into the data warehouse: Load
Extract takes the data out, transform cleans and reshapes it, and load writes it to the destination.
Tick one box.
- LC Data lake
A data lake stores everything raw, with schema on read. A warehouse applies its schema when data is written.
| Technical | Syntactic | Semantic | |
|---|---|---|---|
| The partner can only send files over SFTP, which the bus company's system cannot receive | |||
| The partner's dates are in a different format, so they land in the wrong field | |||
| The partner counts a return ticket as two journeys, but the bus company counts it as one |
Tick one box in each row.
- LThe partner can only send files over SFTP, which the bus company's system cannot receive: Technical
- LThe partner's dates are in a different format, so they land in the wrong field: Syntactic
- LThe partner counts a return ticket as two journeys, but the bus company counts it as one: Semantic
A transport the systems cannot share is technical, a structure that does not match is syntactic, and a different meaning is semantic.
| Multi-factor authentication | Least privilege | Audit logging | Role-based access control | |
|---|---|---|---|---|
| A code from a phone app is needed as well as the password | ||||
| Each person has only the access their job needs | ||||
| A record is kept of who looked at which records, and when | ||||
| Permissions are given to job roles, and staff are given roles |
Tick one box in each row.
- L1 mark for both: A code from a phone app is needed as well as the password: Multi-factor authentication; Each person has only the access their job needs: Least privilege
- L1 mark for both: A record is kept of who looked at which records, and when: Audit logging; Permissions are given to job roles, and staff are given roles: Role-based access control
A second factor is MFA, minimum access is least privilege, a record of access is audit logging, and permissions by role is RBAC.
- LStorage and computing can be scaled up and down quickly
- LSo the company pays only for what it uses, rather than buying servers up front
- LThe provider maintains, patches and backs up the platform
- LResilience: data is held in several locations, so it survives a failure and can be accessed from anywhere
Cloud storage can be scaled up in minutes when the company starts collecting GPS data from every bus, and scaled down again, so it pays only for what it uses instead of buying servers up front. The provider also maintains and patches the platform and keeps copies in several data centres, so the data survives a hardware failure without the company employing its own specialists.
Tick 3 boxes.
- LA Data minimisation
- LB Storage limitation
- LC Purpose limitation
- LNo marks if more than 3 boxes are ticked
The seven principles are lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability.
| Access | Rectification | Erasure | Portability | |
|---|---|---|---|---|
| A passenger asks for a copy of all the data held about them | ||||
| A passenger asks for their incorrect address to be corrected | ||||
| A passenger asks for their data to be deleted | ||||
| A passenger asks for their journey history in a machine-readable file, to give to another company |
Tick one box in each row.
- L1 mark for both: A passenger asks for a copy of all the data held about them: Access; A passenger asks for their incorrect address to be corrected: Rectification
- L1 mark for both: A passenger asks for their data to be deleted: Erasure; A passenger asks for their journey history in a machine-readable file, to give to another company: Portability
A copy is access, a correction is rectification, deletion is erasure, and a machine-readable copy to move elsewhere is portability.
- LAggregate the data: publish counts for each stop, not individual journeys
- LRemove identifiers such as smartcard numbers, and generalise times into bands
- LSuppress small counts, because a stop with one or two passengers could identify a person
Publish totals for each stop rather than individual journeys, with smartcard numbers removed and times grouped into bands such as hours. Counts below a minimum, say ten, should be suppressed, because a quiet stop used by one regular passenger could otherwise reveal when that person travels.
| Data analyst | Data scientist | Data engineer | Data protection officer | |
|---|---|---|---|---|
| Builds and maintains the pipelines that move data into the warehouse | ||||
| Builds a statistical model to predict passenger demand | ||||
| Produces weekly reports and dashboards that answer managers' questions | ||||
| Makes sure the company complies with data protection law |
Tick one box in each row.
- L1 mark for both: Builds and maintains the pipelines that move data into the warehouse: Data engineer; Builds a statistical model to predict passenger demand: Data scientist
- L1 mark for both: Produces weekly reports and dashboards that answer managers' questions: Data analyst; Makes sure the company complies with data protection law: Data protection officer
Engineers build pipelines, scientists build models, analysts report, and the data protection officer oversees compliance.
Tick one box.
- LA Line chart
A line chart shows change over time.
- LDefine the question first, such as which routes and times are over or under capacity
- LCombine the sources, agreeing what a journey means in each so they can be joined
- LClean the data: remove duplicates, standardise formats and handle missing values
- LInvestigate outliers, such as breakdown delays, rather than deleting them
- LStore it securely in a warehouse, with least privilege access
- LAnalyse demand by route, day and hour, using medians and trends, remembering correlation is not causation
- LPresent to managers clearly: suitable charts, plain language and clear recommendations
- LSmartcard data is personal data, so the company needs a lawful basis and must respect purpose limitation
- LMinimise and anonymise or pseudonymise before analysis, and keep data no longer than necessary
- LA justified conclusion or recommendation
The company should first define the question precisely: which routes, days and times are over or under capacity, and where journeys run late. It can then combine the three sources, ticket sales for demand, GPS for actual journey times and surveys for passengers' views, after agreeing definitions so they join correctly, for example whether a return ticket counts as one journey or two. The data must be cleaned before analysis: duplicates removed, dates standardised and missing fares handled. Outliers, such as a 900 minute journey, should be investigated rather than deleted, because a real breakdown pattern matters for a timetable. The cleaned data should be loaded into the warehouse, with access limited to the staff who need it. Analysis should compare demand by route, day and hour, using medians so that occasional delays do not distort typical journey times, and trends across months to allow for seasonal tourists. The findings should be presented to managers in plain language with a few clear charts, such as a line chart of demand through the day, and specific recommendations, such as an extra bus on route 7 at 8am. Legally, smartcard journeys are personal data under the Data Protection Act 2018 and UK GDPR. The company needs a lawful basis, and using ticketing data for planning must be compatible with the purpose it was collected for. It should minimise the data, pseudonymise or aggregate it before analysis, keep it secure and delete it when it is no longer needed, and survey respondents must have been told how their answers would be used. Overall, careful preparation and aggregation let the company plan timetables from real demand while protecting passengers' privacy.
This is an original paper modelled on the real OCR F200 past papers: the same structure, the same balance of topics, the same command words and mark tariffs, 60 marks in 1 hour 15 minutes, exactly as the real paper allows. It is not a past paper. Real past papers are the copyright of the exam board and cannot be republished here, so links to the official papers on the board's own site are on the exam papers page.