Data Analytics F200 Paper A: Fundamentals of Data Analytics

Data is raw facts or figures carrying no context, so the value 14.2 on its own means nothing at all. Information is that data given context and structure so that it means something: 'patient 4412 weighed 14.2 kg on 3 March' identifies the subject, the unit and the time, and can now be acted on.

X-ray and scan images, and the free text clinical notes typed by a vet during a consultation.

Rows 1 and 2 are the same member entered twice, differing only in capitalisation, so an exact string match would not detect the duplicate. The joined dates appear in at least three formats, 07/08/2025, 2025-08-07 and 11/9/25, and the third is ambiguous about which number is the month. Several fields are empty: row 3 has no fee, row 4 no email, row 5 no name, and row 5's email field contains the words 'not supplied' rather than being properly null. Finally there are invalid values: a fee of 4500.00 where every other row is 45.00, a postcode written with spaces between every character, and an email address with no domain.

A format check on the email and postcode fields, applied as the form is submitted, would have rejected 's.mihai@ex' for having no domain and 'N E 3 2 R L' for not matching the pattern of a UK postcode, so neither could ever have reached the file. A range check on the fee field, set to the band the practice actually charges, would have refused 4500.00 and prompted the operator to correct it, and a presence check on name and email would have made those fields impossible to leave blank, which also removes the need for somebody to type 'not supplied' into a field meant to hold an address.

Stage 3 is cleaning and preparing, which produces data that is correctly typed, complete, internally consistent and free of duplicates, so that it can be analysed without the result depending on an accident of entry. Stage 6 is visualising and communicating, which produces a chart and a conclusion a decision maker can act on, since an analysis that stays inside the analyst's notebook changes nothing.

A data warehouse holds structured, modelled data that has already been cleaned and shaped, and it enforces its schema when data is written, so anything that does not fit is rejected and everything inside it is consistent and queryable. A data lake holds data in whatever form it arrived in, structured or not, and applies a schema only when the data is read, so nothing is ever rejected and nothing is guaranteed either. The warehouse answers the questions you already knew you would ask; the lake keeps the material for the questions you have not thought of yet.

Two faults are visible. The first call returns 429 Too Many Requests, which means the tool has exceeded the endpoint's rate limit; the correct behaviour is to pause for the period given in the Retry-After header, here 60 seconds, and try again, rather than hammering the endpoint or treating the call as failed. The second fault is more serious because it is silent. The request asked for a limit of 500, but the response contains 100 items and a 'next' field pointing at page 2, which means the API has paged the result. The note says the client reads the orders array and stops, so it is processing the first hundred records and discarding the rest without any error being raised. Every report built on it is quietly incomplete. The tool must loop, following the next link and appending each page until no next link is returned.

Purpose limitation, data minimisation, and storage limitation.

The controller is whoever decides why personal data is processed and how, and here that is the practice: it decides to keep client and animal records, what to record and for how long. The provider only stores and serves that data on the practice's instructions and has no say in the purpose, which makes it the processor. The distinction matters because accountability does not move with the data: the practice still needs a lawful basis, still has to answer subject access requests and is still answerable to the ICO for the security of the processing, so it must have a written contract obliging the provider to apply appropriate security, use no further sub-processors without permission and report any breach to it promptly.

First, a former employee's account is still active with full rights, which means somebody no longer employed can read and delete everything; the fix is a leaver process that disables the account on the last working day, with a scheduled review to catch any that are missed. Second, least privilege is not being applied: a marketing assistant and a temporary intern can export all data, and a developer and analyst can read payroll, none of which their work requires; each role's permissions should be cut back to the minimum the job needs and granted through the role rather than to the individual. Third, almost every role can delete records and export the entire dataset, so one compromised account could remove or exfiltrate the practice's data; export and deletion should be separated from ordinary access, restricted to named roles, require approval, and be written to an audit log that somebody actually reviews.

A data engineer is responsible for building and maintaining the pipelines that extract data from the source systems, transform it and load it somewhere it can be queried, so that the data arrives reliably, on schedule and in a usable shape. A data analyst is responsible for answering the practice's questions from that data, which means querying it, analysing it, choosing how to present it and explaining the result to the people who will act on it. The engineer makes the data trustworthy; the analyst makes it useful.

Bookings move seasonally within a broad range. They climb through spring and summer from 182 thousand in April to a summer peak of 302 thousand in August, fall back in the autumn, then spike sharply to 418 thousand in December, which is by some distance the highest month. January is the lowest at 142 thousand, less than a third of the December figure, and the following two months recover only slowly. The caution is that this is a single year with nothing to compare it against, so it is impossible to tell whether the December spike is the normal seasonal pattern or a one-off caused by something specific such as a promotion, a competitor closing or a change to the booking system. The chart also says nothing about why any of it happened. Before acting I would put at least two further years alongside it and check what the practice actually did in December, because a plan built on a pattern that occurred once is a plan built on an accident.

The first task is to understand the three datasets before changing any of them: row counts per practice, the distinct values in each field, the formats dates and postcodes arrive in, and the volume of blanks. That produces a baseline the merged file can be reconciled against, which is the only way to prove afterwards that nothing was lost. Cleaning then has to be a set of recorded decisions rather than a button. Duplicates need a defined matching key, probably surname plus postcode plus animal, with a sample of proposed matches reviewed before anything is merged; dates need standardising to one format; and missing values have to be kept and flagged rather than deleted, because if the blanks come disproportionately from one practice then dropping those rows quietly removes that practice from every result. Underneath the technical work sits the harder problem, which is definitional: if one site counts a consultation when it is booked and another when it is paid for, the merged figures are wrong in a way no cleaning will reveal, so the group needs agreed written definitions before it merges anything. For storage, a single relational database or small warehouse is the right shape here, because the data is structured, the questions, appointments per day per site and stock used per procedure, are known in advance, and a modelled store gives consistent answers to everyone. Access must be role based and on least privilege, with clinical records restricted to clinical staff, data encrypted at rest and in transit, and access logged, since this data includes client contact details and payment history. The group is the controller under the Data Protection Act 2018 and the UK GDPR, so it needs a lawful basis, a privacy notice that reflects the merged use, a retention schedule and a process for subject access requests, and it must not quietly repurpose clinical data for marketing. Governance means a named owner for the combined dataset, a data dictionary defining every field, recorded lineage so any figure can be traced back, and a regular quality check. Getting it wrong has two kinds of consequence. The operational one is that staffing and stock decisions are made from numbers that are wrong: duplicates inflate demand, so the group hires for patients who do not exist and orders stock it does not need. The legal and reputational one is more serious, because a merge is exactly when records get exposed to people who should not see them, and a breach of client and clinical data would have to be reported to the ICO and would damage the trust the practice depends on. Of everything above, the agreed definitions matter most, because a cleaning error is visible and fixable while a definitional mismatch produces confident, precise figures that are simply untrue.