DDD  ·  Database Design & Development

Analysis and UK GDPR

Lesson DDD3 of 10 Approx 45 min Conceptual — no database required

Learning Intentions

  • Identify end-user and functional requirements for a database system
  • Describe inputs, processes, and outputs for a database design
  • Explain the six UK GDPR data protection principles with examples
  • Understand the implications of GDPR for individuals and organisations

Success Criteria

  • You can identify who the end users are and what they need to do
  • You can list functional requirements (inputs, processes, outputs)
  • You can explain each of the six GDPR principles with real examples
  • You can identify GDPR breaches in a scenario and explain the implications
🔥 Warm-up
Before we start, test what you already know.

1. A local sports club wants to build a database for member bookings. Who would be an "end user" of this system? TYPE 1

2. Which of these is a "functional requirement"? TYPE 1

3. If you ask a company for a copy of your personal data, which GDPR principle does this relate to? TYPE 1

Key vocabulary

End user
The person who actually uses the database system to do their job (e.g. a member booking a court, admin staff managing bookings).
Functional requirement
What the system must store and process — the inputs, processes, and outputs needed to solve the problem.
Input
Data that the system receives (e.g. member name, booking date, court number).
Process
What the system does with the data (e.g. check if the court is available, record the booking).
Output
The results the system produces (e.g. a booking confirmation, a usage report).
GDPR
General Data Protection Regulation — UK law that protects personal data and gives people rights over their information.
Data protection principle
A rule that organisations must follow when collecting and using personal data.
Personal data
Information about a real person that can identify them (e.g. name, email, address, phone number).

Analysis and Requirements Gathering

What is database analysis?

Before you design or build a database, you must understand the problem you are trying to solve. Analysis means investigating what the business or organisation needs, who will use the system, and what it must do. This happens BEFORE you touch a database — you're asking questions, not yet building.

Good analysis prevents expensive mistakes. If you design the database wrongly because you didn't understand the requirements, you might have to rebuild everything.

End users versus stakeholders

An end user is someone who actually uses the system to do their job. In a sports club booking system:

  • Members who book courts are end users
  • Admin staff who process bookings are end users
  • Managers who review usage reports are end users

Stakeholders are people affected by the system (members, staff, managers, but also the business owner). Some stakeholders use it, others don't — but you need to understand all their needs.

Functional requirements: inputs, processes, outputs

Functional requirements describe what the database must do. Break them into three parts:

Inputs Processes Outputs
Member name, email, phone Store member details Member profile / confirmation
Court number, date, time, member ID Check availability, create booking Booking confirmation
None (query only) Calculate court usage by time of day Usage report
Member ID, new email Update member email address Confirmation message

UK GDPR — The six data protection principles

GDPR is UK law that controls how organisations collect, store, and use personal data. There are six principles:

1. Lawfulness, fairness, and transparency

What it means: Data must be collected and used legally and honestly. People must know it's happening. You need a legal reason (consent, contract, legal obligation, vital interest, public task, or legitimate interest) to process personal data.

Example: A gym collects member email addresses to send booking confirmations — that's transparent (they know why), it's for a contract purpose, and it's fair. Selling their email to a marketing company WITHOUT consent would breach this.

For individuals: You have the right to know what data is collected and why.

2. Purpose limitation

What it means: Data can only be used for the purpose it was collected for. You can't collect email addresses for booking confirmations and then use them to sell gym memberships to competitors.

Example: If a member signs up for court bookings, the gym can't use their phone number for marketing calls without asking first.

For businesses: You must declare your purpose upfront and stick to it.

3. Data minimisation

What it means: Only collect and keep data you actually need. Don't hoard information "just in case".

Example: A booking system needs member name, email, and phone — so they can confirm bookings. Asking for their mother's maiden name or childhood hobbies violates this because it's not necessary.

For individuals: You have the right to have unnecessary data deleted.

4. Accuracy

What it means: Personal data must be accurate and kept up to date. If someone's address changes, you should update it.

Example: A customer moves house and updates their address with a shop. The shop must update their database; if they don't and send mail to the old address, they breach GDPR.

For individuals: You have the right to ask for incorrect data to be corrected.

5. Storage limitation

What it means: Don't keep personal data longer than you need it. Once you've served the purpose, delete it.

Example: A customer buys something once. After the order is fulfilled and the return window closes, the company should delete their details. Keeping old customer records "just in case they order again" violates this.

For individuals: You have the right to be forgotten — to have your data deleted if there's no good reason to keep it.

6. Integrity and confidentiality (security)

What it means: Personal data must be kept secure from theft, loss, or misuse. Use encryption, strong passwords, access controls, backups.

Example: A clinic stores patient records digitally but leaves the server unencrypted and with a weak password. A hacker steals thousands of records. This is a serious GDPR breach.

For individuals: Your data should be protected as if it's valuable.

Implications for individuals

  • Right to know: You can ask a company what data they hold on you and get a copy (Subject Access Request).
  • Right to correction: If data is wrong, you can ask them to fix it.
  • Right to deletion: If there's no good reason to keep your data, you can ask them to delete it (right to be forgotten).
  • Right to restrict: You can ask a company to limit how they use your data.
  • Right to complain: If you think a company is breaking GDPR, you can report them to the ICO (Information Commissioner's Office).

Implications for organisations

  • Must have legal basis: You can't just collect data because you want to. You need consent, a contract, legal obligation, or legitimate business interest.
  • No data selling without consent: You can't sell customer data to third parties without asking permission.
  • Must report breaches: If personal data is lost or stolen, you must tell the ICO within 72 hours and notify affected people.
  • Can't keep unnecessary data: Regularly delete old data. The saying is: "Don't collect it if you don't need it; if you don't need it, delete it."
  • Data Protection Officer (DPO): Large organisations must appoint a DPO to ensure GDPR compliance.
  • Privacy by design: When building a system, security must be built in from the start, not added later.
  • Fines: Breaking GDPR can result in fines up to €20 million or 4% of global revenue — whichever is higher.

Worked examples

Example 1 — Requirements analysis for a sports club

Scenario: A local handball club wants a database to manage members and their court bookings.

1
End users: Members (booking courts), admin staff (confirming bookings), managers (viewing reports).
2
Functional requirements — inputs: Member name, email, phone; court number, date, time for bookings.
3
Functional requirements — processes: Store member details; check court availability; create bookings; send confirmation emails; generate usage reports.
4
Functional requirements — outputs: Booking confirmation (email); usage report (by time of day, by court, by member).
Example 2 — GDPR principles applied to a booking system

Scenario: The handball club collects member phone numbers to send booking reminders.

1
Principle 1 (Lawfulness & transparency): Members must be told upfront that their phone number will be used for booking reminders. The club has a contract with them (membership) so has legal basis.
2
Principle 2 (Purpose limitation): The club can use the phone number to send booking reminders, but NOT to sell it to other companies or use it for marketing without consent.
3
Principle 3 (Data minimisation): Ask only for the phone number needed for reminders. Don't ask for next of kin, employment history, or other unrelated data.
4
Principle 4 (Accuracy): If a member changes their phone number, update the database immediately.
5
Principle 5 (Storage limitation): If a member leaves the club, delete their details within a reasonable time (e.g. 30 days).
6
Principle 6 (Security): Use encrypted storage, strong passwords, and regular backups. If the database is hacked, report it within 72 hours.
Example 3 — GDPR breach scenario

Scenario: A retail company collects customer email addresses for order confirmations. Two years later, they still have emails from customers who made one purchase. They use these emails to send promotional campaigns without asking.

1
Principle 2 breach (Purpose limitation): Email was collected for order confirmation, not marketing. Using it for marketing without consent violates GDPR.
2
Principle 3 breach (Data minimisation): Two-year-old inactive customer data should have been deleted. Keeping it "just in case" they come back violates GDPR.
3
What should happen: Customers can complain to the ICO. The company faces fines (up to €20 million). The company should delete old data and only send marketing to people who explicitly opted in.
Now you try

Scenario: A hospital wants to build a database to manage patient appointments and medical records. You have been asked to analyse the requirements.

  1. Identify who the end users would be.
  2. List at least three functional requirements (inputs, processes, outputs).
  3. For each functional requirement, identify which GDPR principle is most relevant and explain why.

End users: Doctors (recording appointments and medical history), nurses (updating patient status), receptionists (booking appointments), patients (viewing their own records).

Functional requirements:

  • Input: Patient name, DOB, medical history, medications. Process: Store patient record. Output: Patient profile, medical summary. GDPR principle: Data minimisation (only collect data needed for treatment) and accuracy (keep medical data up-to-date).
  • Input: Appointment date, time, doctor. Process: Check availability, book appointment. Output: Appointment confirmation. GDPR principle: Purpose limitation (appointment data should not be sold or used for marketing).
  • Input: None (query). Process: Generate usage report (e.g. patient no-show rates). Output: Anonymised usage report. GDPR principle: Security and data minimisation (reports should not include identifiable details unless necessary).
⚠️ Common mistakes
Confusing GDPR with security. GDPR is not just about having a strong password. It's about when and how you collect data, what you do with it, and how long you keep it. A company can be hacked and lose data (a security failure) but also break GDPR by collecting too much data in the first place (a GDPR failure). Both are problems, but they're different.
Thinking consent solves everything. Yes, consent is one legal basis for processing data, but it's not the only one. A hospital can process medical data under "vital interest" (someone's life or health is at stake) without asking permission. A company can process data under "contract" (you agreed to it when you bought). Always ask: "What is my legal basis?" not just "Can I get consent?"
Keeping data "just in case" it's useful later. GDPR says no. Once you've served the purpose, delete it. A gym that keeps members' data for five years after they leave "in case they rejoin" is breaking GDPR. Set a retention policy: "We keep booking records for two years, then delete them." Stick to it.
Assuming anonymised data doesn't need protection. If you've truly anonymised it (removed all identifiers so you can't tell whose data it is), GDPR doesn't apply. But many datasets that companies claim are "anonymised" actually aren't — you can still identify people by combining information. If there's any way to link data back to a person, GDPR still applies. Be honest: is it truly anonymised?
💡 Exam tip

When asked to "analyse requirements" or "identify functional requirements", use the IPO model: Describe what data goes IN (input), what the system must DO with it (process), and what comes OUT (output). This shows the examiner you understand the problem end-to-end.

When asked about GDPR: Name the principle AND explain what it means in the context of the scenario. Don't just say "Principle 1 — lawfulness." Say: "Principle 1 — the company must be transparent about why they're collecting emails. They should tell customers upfront that emails will be used for order confirmations."

Know the rights: Examiners love asking what people can do under GDPR. Memorise: right to know, right to correct, right to delete, right to restrict, right to data portability.

Task set — Practice questions

1. Which of the following is an end user in a library booking system? TYPE 1

2. Which GDPR principle states that organisations can only use personal data for the purpose it was collected for? TYPE 1

3. Which one of these violates the data minimisation principle? TYPE 1

4. What does the GDPR "right to be forgotten" allow a person to do? TYPE 1

5. A hairdresser wants a database to store client contact details and appointment history. Using the IPO model (input, process, output), describe one functional requirement for this system. TYPE 2

Write 2-3 sentences.

6. A company collects customer email addresses when they buy a product. Two years later, they send promotional emails to all old customers without asking. Which GDPR principles are being broken? Explain each one. TYPE 2

Write 4-5 sentences covering 2-3 principles.

7. You are analysing requirements for a school database to manage student attendance and grades. Identify the end users and list three functional requirements (using input, process, output). TYPE 2

Write 5-7 sentences.

8. A fitness centre collects member photos, names, ages, addresses, and phone numbers when they join. They keep this data forever, even for members who left five years ago. Analyse this scenario against all six GDPR principles. Explain what the gym should do to comply with GDPR. TYPE 3

Write 10-12 sentences covering all six principles and remediation.

9. You are a Data Protection Officer for a transport company. The company wants to collect driver location data (GPS) to optimise routes and improve delivery times. Analyse the requirements under GDPR. What data should be collected, how long kept, and who should have access? What risks and breaches could occur if not done carefully? TYPE 3

Write 10-12 sentences covering data collection, retention, access, and risks.

10. Compare a company that collects customer phone numbers with full transparency (telling them why, limiting use to delivery notifications, deleting data after 6 months, using encryption) to a company that does none of these. Analyse both against all six GDPR principles and explain the legal and business implications for each. TYPE 3

Write 12-14 sentences comparing both scenarios.

Teacher notes — Shift+T to hide

Suggested timing: 45 minutes. Warm-up 5 min; vocabulary 5 min; notes (analysis) 10 min; notes (GDPR) 12 min; now you try 3 min; task set 10 min.

Key emphasis: Pupils often conflate requirements gathering with database design. Requirements analysis is about UNDERSTANDING the problem (who, what, why), not building the solution yet. Use a real-world analogy: "An architect doesn't start building a house until they've asked the client 'How many bedrooms? What's your budget? Who lives there?' Analysis is asking those questions."

IPO model strength: The input-process-output framework is powerful because it forces clear thinking. Have pupils practice with their own scenarios (e.g. "What's a functional requirement for a cinema booking system?") and push them to break it into IPO chunks.

GDPR is here and it matters: Exams have shifted toward GDPR because it's real, it affects businesses, and pupils live in a GDPR world (their data is protected). Make it personal: "If you posted on social media, that's your personal data under GDPR. You have rights over it." Then connect to why organisations must care (fines, reputation, legal liability).

Common teaching pitfall: Pupils memorise the six principles as a list and forget to explain them. Push for application: "Not 'Principle 1 is transparency' but 'Principle 1 means the company must tell you upfront how it will use your email address.'"

Exam command words: "Identify end users" (list who uses it), "Describe functional requirements" (explain inputs, processes, outputs), "Explain implications" (say what GDPR means for that person or business). Teach pupils to answer the question asked.