Five Stars and What They Hide

Overview

The Food Standards Agency publishes hygiene ratings for every registered food business in the UK. The data is open, structured, and — once you have more than one local authority in the same table — considerably messier than it looks.

This project builds a relational platform over 21,209 establishments across seven authorities, and organises the whole design around six explicit research questions.

Dataset and ingestion

FHRS data across seven local authorities. Authorities publish on their own schedules with their own conventions, so ingestion has to reconcile differences in rating scheme, date handling and address structure before anything is comparable.

Relational decomposition

Six relations, described in the report as BCNF, with one documented exception discussed below. The decomposition is driven by the questions: if a question requires grouping by authority and rating over time, the schema has to make that a join rather than a scan of a denormalised blob.

Loader and validation

Loading public data is where the honesty happens. Records arrive with missing ratings, inconsistent scheme identifiers, and addresses that do not parse. The loader validates and reports rather than silently coercing, because a row quietly defaulted to zero becomes a finding later.

Query design and traceability

Each of the six research questions maps to a named query. This is the part I would defend hardest: it means the analysis cannot drift away from what was asked, and a reader can check any stated finding by reading one query rather than reverse-engineering an application.

Web application

Node, Express and EJS. Server-rendered, because the value is in the data and the queries, not in a client-side framework. Accessibility was treated as a requirement of the interface rather than an audit at the end.

The normalisation trade-off

The report states six relations in BCNF, and then explicitly acknowledges that the Establishment relation does not reach strict 3NF, because local_authority_id functionally determines scheme_id.

I am keeping that acknowledgement prominent rather than burying it, because it is the most useful thing in the report. Every authority uses exactly one rating scheme, so the dependency is real. Decomposing it further would have added a join to almost every query for a correctness property that the loader already enforces. That is a defensible trade — but it is a trade, and pretending the schema is fully normalised would be false.

Findings

The report's findings are observational: distributions of ratings across authorities, and the ways aggregate ratings conceal variation within them. They describe what the data shows. None of them establishes cause, and none is presented as though it did.

Scope of the analysis

• Seven local authorities, which is the coverage the study was designed around.
• Establishments are inspected on their own schedules, so an aggregate mixes ratings from different dates — which is itself one of the things the analysis surfaces.
• The findings are observational and descriptive, describing what the data shows across these authorities at the time of the load.

Where I would take this next

• A pinned, reproducible data snapshot, so every figure can be regenerated from the repository alone.
• Automated schema tests asserting the stated normal forms, turning the normalisation trade-off above into an enforced invariant.
• A full accessibility audit of the web application.
• Wider authority coverage, which is what a between-authority comparison would need.

The technical-report treatment of this same work — including the question of whether it counts as research at all — is in the research dossier.