2023¶

Question 1 — Cinema Chain Database (25 marks)¶

(i) ER Model [8 marks]¶

Assumptions¶

1. A movie is uniquely identified by a movieID. Each movie has a title, director, and release date.
2. A theatre is uniquely identified by a theatreID. Each theatre has an address, a name, and a set of screens.
3. A screen belongs to exactly one theatre and is uniquely identified within that theatre (e.g., "Screen 1" at "Theatre A"). A screen may host multiple screenings over time.
4. A screening is an instance of a movie being shown at a particular screen at a particular time. Each screening has a start date, start time, and running time (inherited from the movie; stored explicitly to allow changes).
5. A movie may be screened at many theatres, and a theatre may screen many movies — the relationship between Movie and Theatre is many-to-many, resolved through Screening.
6. A screening is fully identified by the combination of theatreID, screenNumber, date, and startTime (a given screen shows at most one movie at a given time). For simplicity, we treat Screening as a weak entity dependent on Theatre.

Entities and Attributes¶

Screen is a weak entity: it depends on Theatre for its identity (a screen number alone is not globally unique — it is only unique within a theatre). Its partial key is screenNumber, and it has a total identifying relationship with Theatre.

Screening is also a weak entity: it depends on Screen (and transitively on Theatre) for its identity. Its partial keys are date and startTime, which together with the owner Screen's key uniquely identify a screening instance.

Specialisation / Generalisation¶

None required. No subtype relationships are suggested by the requirements.

Relationships¶

Note: The choice to model Screening as a weak entity (with a composite PK) is one valid approach. An alternative — used in the course's canonical cinema example — is to treat Screening as a strong entity with its own single primary key (screeningID) and foreign keys to both Movie and Screen. Both approaches are correct; the weak-entity approach used here is more normalised but the strong-entity approach is equally valid and commonly used in practice.

ER Diagram (Textual Representation)¶

┌─────────────────┐
│     Movie       │
├─────────────────┤
│ *movieID        │
│   title         │
│   director      │
│   releaseDate   │
└─────────────────┘
         │
         │ 1
         │ Screens
         │ 1
         │
┌────────┴─────────┐
│    Screening      │  ← weak entity (dashed rectangle)
├─────────────────┤
│ *date            │  ← partial key (double underline)
│ *startTime       │  ← partial key (double underline)
│   runningTime    │
└────────┬─────────┘
         │
         │ 1
         │ Shows
         │ N
         │
┌────────┴─────────┐
│     Screen        │  ← weak entity (dashed rectangle)
├─────────────────┤
│ *screenNumber    │  ← partial key (double underline)
│   capacity       │
│   screenType     │
└────────┬─────────┘
         │
         │ N
         │ Has
         │ 1
         │
┌────────┴─────────┐
│     Theatre       │
├─────────────────┤
│ *theatreID       │
│   name           │
│   address        │
└─────────────────┘

Key notation:

• * denotes primary key attributes (underlined in a hand-drawn diagram).
• Double underline denotes partial keys of weak entities.
• Dashed rectangle for weak entities (Screen, Screening).
• Double line for total participation (Screen → Theatre, Screening → Screen).
• Single line for partial participation (Theatre → Screen, Screen → Screening).

Marks Breakdown (8 marks)¶

(ii) Relational Mapping [5 marks]¶

Functional Dependencies¶

Relational Schema¶

Movie(movieID PK, title, director, releaseDate)

Theatre(theatreID PK, name, address)

Screen(theatreID FK NOT NULL, screenNumber, capacity, screenType,
       PK: (theatreID, screenNumber),
       FK: theatreID REFERENCES Theatre(theatreID))

Screening(theatreID FK NOT NULL, screenNumber FK NOT NULL,
          date, startTime, runningTime, movieID FK NOT NULL,
          PK: (theatreID, screenNumber, date, startTime),
          FK: (theatreID, screenNumber) REFERENCES Screen(theatreID, screenNumber),
          FK: movieID REFERENCES Movie(movieID))

Mapping rationale:

1. Strong entities (Movie, Theatre) map directly — each becomes a relation with the same attributes.
2. Weak entity Screen maps to a relation with its own attributes plus the full PK of its owner (Theatre) as a FK. The PK of Screen is the composite of the owner's PK and Screen's partial key: (theatreID, screenNumber). The FK to Theatre has NOT NULL because Screen has total participation in Has.
3. Weak entity Screening maps to a relation with its own attributes (runningTime) plus the full PK of its owner (Screen) as FKs, plus date and startTime as part of the PK. The PK is (theatreID, screenNumber, date, startTime). The FK to Screen is (theatreID, screenNumber).
4. Relationship "Screens" (Movie — Screening, 1:N): Since Screening is on the "many" side (a movie can be screened many times), the FK movieID is placed in Screening, referencing Movie(movieID). NOT NULL enforces that every screening shows exactly one movie.

Marks Breakdown (5 marks)¶

(iii) SQL Queries [12 marks]¶

a. Insert a new movie "Titanic 2" (3 marks)¶

INSERT INTO Movie (movieID, title, director, releaseDate)
VALUES (1012, 'Titanic 2', 'James Cameron', '2023-01-15');

Explanation: The Movie table requires movieID, title, director, and releaseDate. The question specifies movieID = 1012 and title "Titanic 2". Reasonable values are provided for director and releaseDate. The INSERT statement includes all four attributes since Movie has no NOT NULL defaults on any of them.

b. Movies with running time < 90 minutes, released in 2019 (2 marks)¶

SELECT DISTINCT m.title
FROM Movie m
JOIN Screening s ON m.movieID = s.movieID
WHERE s.runningTime < 90
  AND m.releaseDate >= '2019-01-01'
  AND m.releaseDate <  '2020-01-01';

Explanation: Running time is stored on the Screening relation (to allow different screenings of the same movie to have different running times), so a join between Movie and Screening is required to filter by both running time and release date. DISTINCT ensures each movie title appears only once even if it has multiple screenings matching the criteria.

c. Screenings today, showing before 12:00 (3 marks)¶

SELECT *
FROM Screening
WHERE date = CURDATE()
  AND startTime < '12:00:00';

Explanation: CURDATE() returns today's date (in MySQL/PostgreSQL equivalent). The condition startTime < '12:00:00' selects screenings whose start time is before noon. The SELECT * returns all screening details; alternatively, specific columns can be listed.

d. Screenings today, finishing before 12:00 (4 marks)¶

SELECT *
FROM Screening
WHERE date = CURDATE()
  AND (startTime + INTERVAL runningTime MINUTE) < '12:00:00';

Explanation: A screening finishes at startTime + runningTime. The query computes the finish time by adding the runningTime (in minutes) to the startTime, and checks whether this computed finish time is before 12:00. This is more complex than © because it requires arithmetic on the time and duration.

Alternative (PostgreSQL syntax):

SELECT *
FROM Screening
WHERE date = CURRENT_DATE
  AND (startTime::time + (runningTime || ' minutes')::interval) < TIME '12:00:00';

Alternative (standard SQL with explicit calculation):

SELECT *
FROM Screening
WHERE date = CURRENT_DATE
  AND TIME '12:00:00' > CAST(
      DATEADD(MINUTE, runningTime, startTime) AS TIME
  );

The exact syntax varies by DBMS; the key insight is computing finishTime = startTime + runningTime and comparing with 12:00.

Marks Breakdown (12 marks)¶

Question 2 — Integrity Constraints (25 marks)¶

(i) Three Types of Integrity Constraints [6 marks]¶

Integrity constraints are rules that maintain the correctness and consistency of data in a relational database. Three fundamental types are:

1. Entity Integrity Constraints¶

An entity integrity constraint specifies that no part of a primary key can contain NULL values. This ensures that every tuple in a relation can be uniquely identified — a primary key with NULL would mean some entities are unidentifiable.

• Built-in enforcement: The relational model requires that primary key attributes are NOT NULL. Any attempt to insert or update a tuple with a NULL primary key value is rejected.
• Example: In a Student(studentID, name, email) table, studentID cannot be NULL. Every student must have a valid ID to be uniquely identified.

Entity integrity is the most fundamental constraint — it guarantees that every entity instance in the database is distinguishable from every other.

A key constraint ensures that each tuple (row) in a relation is uniquely identifiable. It is enforced by defining one or more attributes as a primary key (or unique key).

• A primary key must be unique (no two rows share the same key value) and not null (every row must have a key value).
• Example: studentID in a Student table — no two students can share the same ID, and every student must have an ID.

Key constraints enforce entity integrity — the principle that every entity instance must be distinguishable from every other.

3. Referential Integrity Constraints¶

Referential integrity ensures that relationships between tables remain consistent. It is enforced through foreign keys: a foreign key attribute in one relation must either be NULL or match a primary key value in the referenced relation.

• If relation R1 has a foreign key referencing relation R2, then every non-null value of the foreign key in R1 must exist as a primary key value in R2.
• Example: In Enrolment(studentID, moduleCode), if studentID references Student(studentID), then every studentID in Enrolment must exist in Student. Deleting a student without deleting their enrolments would violate referential integrity.

Referential integrity is typically enforced with ON DELETE and ON UPDATE actions: CASCADE, SET NULL, SET DEFAULT, or RESTRICT/NO ACTION.

Summary Table¶

Marks Breakdown (6 marks)¶

(ii) Referential Integrity in SQL [6 marks]¶

Referential integrity is specified in SQL using the FOREIGN KEY clause in a CREATE TABLE or ALTER TABLE statement. The syntax declares which column(s) in the referencing (child) table correspond to the primary key (or unique key) of the referenced (parent) table.

Example¶

Consider a library database with Member and BookLoan tables:

CREATE TABLE Member (
    memberID    INTEGER PRIMARY KEY,
    name        VARCHAR(100) NOT NULL,
    email       VARCHAR(200) UNIQUE NOT NULL
);

CREATE TABLE BookLoan (
    loanID      INTEGER PRIMARY KEY,
    memberID    INTEGER NOT NULL,
    bookISBN    VARCHAR(13) NOT NULL,
    loanDate    DATE NOT NULL,
    dueDate     DATE NOT NULL,
    FOREIGN KEY (memberID) REFERENCES Member(memberID)
        ON DELETE RESTRICT
        ON UPDATE CASCADE
);

Note: The default action in SQL when a foreign key constraint is violated (without explicit ON DELETE/ON UPDATE clauses) is to reject the operation. The explicit ON DELETE RESTRICT and ON UPDATE CASCADE clauses override this default to specify the desired behaviour.

Explanation¶

• FOREIGN KEY (memberID) declares that the memberID column in BookLoan is a foreign key referencing the memberID primary key in Member.
• Referential integrity enforcement:
• INSERT: A new row in BookLoan with a memberID that does not exist in Member is rejected. This prevents orphaned loan records pointing to non-existent members.
• UPDATE (of the parent): ON UPDATE CASCADE means that if a Member.memberID is updated, the corresponding memberID values in BookLoan are automatically updated to match. This preserves the relationship.
• DELETE (of the parent): ON DELETE RESTRICT means that a Member cannot be deleted if there are existing BookLoan records referencing that member. This prevents accidental deletion of members who still have active loans. An alternative would be ON DELETE CASCADE (automatically delete all loans when a member is deleted) or ON DELETE SET NULL (set memberID to NULL in loans, if nullable).

Why Referential Integrity Constraints Are Appropriate¶

1. Prevents orphaned records: Without the foreign key constraint, a loan could reference a member that has been deleted, leaving the database in an inconsistent state.
2. Maintains data consistency: The constraint ensures that the relationship between Member and BookLoan is always valid — every loan is attributable to a real member.
3. Automated enforcement: The database engine enforces the constraint automatically on every insert and update, removing the burden from application logic and preventing bugs.
4. Semantic clarity: The foreign key declaration documents the intended relationship between tables, making the schema self-describing.

Marks Breakdown (6 marks)¶

(iii) Assertions [9 marks]¶

An assertion is a general integrity constraint expressed in SQL that can involve multiple relations, aggregate functions, and complex logical conditions — capabilities that go beyond what can be expressed with simple CHECK, PRIMARY KEY, or FOREIGN KEY constraints.

SQL Assertion¶

CREATE ASSERTION maximum_inventory CHECK (
    (SELECT SUM(sale_price) FROM Movie)
  +
    (SELECT SUM(sale_price) FROM Music)
    <= 1000000
);

Explanation¶

This assertion ensures that the total sale_price of all movies plus the total sale_price of all music never exceeds €1,000,000.

• SELECT SUM(sale_price) FROM Movie computes the sum of sale prices across all rows in the Movie table.
• SELECT SUM(sale_price) FROM Music computes the sum across all rows in the Music table.
• The CHECK condition evaluates the arithmetic sum of these two aggregates.
• If the sum exceeds 1,000,000, the assertion is violated, and the database rejects the triggering operation (INSERT or UPDATE).

When the Assertion Is Checked¶

The assertion is evaluated whenever any modification to either Movie or Music could affect the condition:

• INSERT into Movie: The new row's sale_price is added to the existing sum. If the new total exceeds €1,000,000, the insert is rejected.
• UPDATE of Movie.sale_price: The price change is reflected in the sum. If the new total exceeds the limit, the update is rejected.
• DELETE from Movie: The removed row's sale_price is subtracted. This cannot violate the assertion (the sum decreases), but the assertion is still evaluated.
• INSERT/UPDATE/DELETE on Music: Same logic applies symmetrically.

Important Notes¶

1. SQL standard compliance: The CREATE ASSERTION statement is part of the SQL standard (SQL-92 and later), but very few commercial DBMS implementations (e.g., PostgreSQL, MySQL, SQL Server) actually support it. In practice, triggers are used as a workaround.
2. Performance implications: Assertions require the database to evaluate the condition on every relevant modification, which can be expensive for aggregate conditions involving large tables.
3. The assertion is a declarative constraint: Unlike triggers (which are procedural), assertions state what must be true, not how to enforce it. The database engine determines the most efficient way to check the condition.

Example of a Rejected Operation¶

Suppose Movie currently has total sale_price of €800,000 and Music has €300,000 (total €1,100,000). An attempt to insert a new movie with sale_price = €50,000 would be rejected because €850,000 + €300,000 = €1,150,000 > €1,000,000.

Marks Breakdown (9 marks)¶

(iv) Assertions vs Triggers [4 marks]¶

Key Difference¶

The fundamental difference is declarative vs procedural. An assertion states a condition that must always be true, leaving the DBMS to decide how to enforce it. A trigger defines a sequence of actions that execute in response to database events, giving the developer full control but also full responsibility for correctness.

Practical Reality¶

Because assertions are not widely supported, triggers are the practical alternative for implementing complex integrity constraints. However, triggers introduce procedural complexity and are harder to reason about formally.

Marks Breakdown (4 marks)¶

Question 3 — Transactions (25 marks)¶

(i) What Is a Transaction and How Transactions Can Fail [8 marks]¶

Definition of a Transaction¶

A transaction is a logical unit of work that accesses and possibly modifies various data items. It is a sequence of one or more database operations (reads, writes, deletes, inserts) that are treated as a single, atomic unit of execution.

Formally, a transaction is a transition from one consistent state of the database to another consistent state. If the transaction completes successfully, all its changes are permanently recorded (committed). If it fails, all its changes are undone (rolled back), leaving the database as if the transaction never occurred.

In SQL, transactions are delimited by:

• BEGIN TRANSACTION (or START TRANSACTION) — marks the start
• COMMIT — permanently saves all changes
• ROLLBACK — undoes all changes since the transaction began

How Transactions Can Fail¶

Transactions can fail for several reasons, broadly categorised as abnormal termination (abort) or successful completion (commit):

1. System Errors (Soft Failures)¶

• Hardware failures: Power loss, disk crashes, network failures. These can cause transactions to be interrupted mid-execution.
• Software errors: Bugs in the DBMS, operating system crashes, or application errors.
• Recovery mechanism: The DBMS uses its recovery subsystem (based on the recovery log/wal) to roll back uncommitted transactions and redo committed transactions that were not fully written to disk.

2. Logical Errors (User Errors)¶

• Constraint violations: A transaction attempts to insert a duplicate primary key, violate a foreign key constraint, or breach a CHECK constraint. The specific statement fails, and depending on the DBMS, the entire transaction may be rolled back.
• Division by zero, type errors, etc.: Runtime errors in SQL expressions.
• Deadlocks: Two or more transactions are each waiting for locks held by the other. The DBMS's deadlock detector identifies the cycle and aborts one or more transactions (the "victims").
• Timeout: A transaction waits too long for a lock and is aborted to prevent indefinite blocking.

3. Physical Failures (Hard Failures)¶

• Media failures: Disk platter damage, controller failure. These require recovery from backups and redo/undo processing.
• Recovery mechanism: The DBMS restores the database from the latest backup and replays the transaction log to recover all committed transactions up to the point of failure.

Transaction Lifecycle¶

Begin → Execute Operations → [Error/Commit?] → Commit (permanent) / Rollback (undo)

ACID Properties and Failure¶

The ACID properties (Atomicity, Consistency, Isolation, Durability) are what ensure that transaction failures do not corrupt the database. Atomicity and durability are particularly relevant to failure handling:

• Atomicity ensures that a failed transaction's effects are completely undone.
• Durability ensures that a committed transaction's effects survive any subsequent failure.

Marks Breakdown (8 marks)¶

(ii) ACID Properties [8 marks]¶

ACID is an acronym describing the four properties that guarantee reliable processing of database transactions.

1. Atomicity — "All or Nothing"¶

Atomicity ensures that a transaction is treated as an indivisible unit of work. Either all of the transaction's operations are permanently applied to the database, or none are. There is no partial execution.

• Why it matters: If a transaction transfers €500 from Account A to Account B, atomicity guarantees that both the debit from A and the credit to B succeed together. If the credit to B fails after A has been debited, atomicity requires the debit to be rolled back.
• How it is implemented: The DBMS uses a transaction log (write-ahead log / WAL). Before any change is written to the database, the before-image (and optionally after-image) is logged. If a transaction aborts, the log's before-images are used to undo the changes. If a transaction commits, the log confirms the commit before the DBMS returns success.

2. Consistency — "Valid State to Valid State"¶

Consistency ensures that a transaction transforms the database from one valid state to another valid state, preserving all integrity constraints (domain, key, referential, and any user-defined constraints).

• Why it matters: Consistency is the overarching property that all others serve. If a transaction violates a constraint (e.g., negative balance), the database must detect this and abort the transaction, maintaining consistency.
• How it is implemented: The DBMS enforces constraints automatically at the schema level (PRIMARY KEY, FOREIGN KEY, CHECK, UNIQUE). The application is responsible for higher-level consistency rules (e.g., "total balance across accounts must remain constant").
• Note: Consistency is the property that depends on correct application logic. The DBMS enforces declarative constraints, but business rules must be implemented by the developer (via triggers, assertions, or application code).

3. Isolation — "Concurrent Transactions Don't Interfere"¶

Isolation ensures that concurrent transactions execute as if they were serialised (executed one after another). Each transaction perceives the database as if it were the only transaction running.

• Why it matters: Without isolation, concurrent transactions can produce incorrect results through phenomena such as:
• Dirty read: Reading data written by an uncommitted transaction.
• Non-repeatable read: Re-reading a row and getting a different value because another transaction modified it.
• Phantom read: Re-executing a query and getting different rows because another transaction inserted or deleted matching rows.
• How it is implemented: The DBMS uses locking (e.g., Two-Phase Locking), timestamp ordering, or multiversion concurrency control (MVCC) to control access to data during concurrent execution. Different isolation levels (Read Uncommitted, Read Committed, Repeatable Read, Serializable) offer different guarantees with different performance trade-offs.

4. Durability — "Committed Survives"¶

Durability guarantees that once a transaction has committed, its changes are permanent and will survive any subsequent system failure (power loss, crash, disk failure).

• Why it matters: Users and applications rely on the fact that once a transaction reports success, the data is safely stored. If durability were not guaranteed, a crash after COMMIT but before data was written to disk would lose the committed changes.
• How it is implemented: The DBMS writes transaction changes to non-volatile storage (disk). The write-ahead log (WAL) protocol ensures that log records are written to stable storage before the corresponding data pages. After a crash, the DBMS replays the log during recovery to redo all committed transactions and undo any uncommitted ones.

Summary Table¶

Marks Breakdown (8 marks)¶

(iii) Transaction Failure Scenario [9 marks]¶

Scenario Analysis¶

We have two transactions executing concurrently:

• T₁ (Flight Transfer): Transfers a reservation from Flight X to Flight Y. This involves:
• Reading reserved_seats_X (current seats on Flight X)
• Reading reserved_seats_Y (current seats on Flight Y)
• Decrementing reserved_seats_X (freeing a seat on Flight X)
• Incrementing reserved_seats_Y (occupying a seat on Flight Y)

• Committing

• T₂ (Flight Reservation): Reserves a seat on Flight X. This involves:

• Reading reserved_seats_X
• Incrementing reserved_seats_X
• Committing

T₁ fails after reading reserved_seats_Y.

Error Type: Lost Update¶

The specific error that occurs is a Lost Update problem, which arises from inadequate isolation between concurrent transactions.

What happens:

1. T₁ reads reserved_seats_X and reserved_seats_Y.
2. T₁ fails and is rolled back before it can update reserved_seats_X or reserved_seats_Y.
3. T₂ reads reserved_seats_X (which still shows the old value, since T₁'s read never modified it — but the problem is more subtle).

The deeper issue: T₁ read reserved_seats_X = 100 and planned to decrement it to 99. But T₁ aborted before writing. T₂ then reads reserved_seats_X = 100 and increments it to 101. The correct final value should have been 100 (T₁ freed a seat → 99, then T₂ booked it → 100). Instead, the database ends up with 101 — T₁'s decrement was lost because T₁ never got to write it. This is the lost update anomaly: a committed update (T₂'s increment) is based on stale data because a concurrent update (T₁'s decrement) was rolled back before being applied.

Detailed Analysis¶

Let's assume the initial state is:

• reserved_seats_X = 100
• reserved_seats_Y = 50

Possible interleaving:

In this scenario, T₁'s failure and rollback means its intended transfer never happened. T₂'s reservation proceeds normally. The database ends up with reserved_seats_X = 101 (T₂'s +1) and reserved_seats_Y = 50 (unchanged).

The lost update is: T₁'s intended decrement of reserved_seats_X (from 100 to 99) was never applied. The seat was never freed on Flight X.

Isolation Level Required to Prevent This¶

• Read Committed: Prevents dirty reads but not lost updates. A lost update occurs when two transactions read the same value and both write based on it — Read Committed does not prevent this because each transaction sees the last committed value, not intermediate uncommitted writes.
• Repeatable Read: Prevents dirty reads and non-repeatable reads (re-reading a row returns the same value). However, it does not prevent lost updates — two transactions can both read the same value and both write based on it, with one update being lost. Some DBMS implementations (e.g., PostgreSQL) add extra protections, but the SQL standard does not guarantee lost update prevention at this level.
• Serializable: The highest isolation level. Guarantees that concurrent transactions produce the same result as if they were executed serially. This would prevent the lost update by ensuring T₁ completes all its operations before T₂ begins (or vice versa).

Recovery Mechanism¶

Since T₁ fails and is rolled back, the DBMS's recovery subsystem uses the undo log to reverse any changes T₁ made before the failure. In this scenario, T₁ only performed reads (no writes) before failing, so there is nothing to undo. The database remains in its original consistent state.

T₂, which committed successfully, has its changes preserved (durability).

Marks Breakdown (9 marks)¶

Question 4 — GDPR (25 marks)¶

(i) John's GDPR Rights [8 marks]¶

Overview of GDPR Rights¶

Under the General Data Protection Regulation (GDPR), data subjects (individuals whose personal data is processed) have eight core rights. In John's case, the most relevant rights are:

1. Right to be Informed (Articles 13 and 14)¶

Data subjects have the right to be provided with clear, transparent information about how their personal data is being used. This includes:

• The identity of the data controller.
• The purposes of processing.
• The lawful basis for processing.
• How long the data will be retained.
• Who the data will be shared with.

John's situation: John "never agreed" to receiving marketing emails, which strongly suggests Telemate did not inform him about, nor obtain consent for, this processing activity. This is a violation of the right to be informed.

2. Right of Access (Article 15)¶

Data subjects can request confirmation of whether their personal data is being processed, and if so, access to that data along with information about the purposes, categories, recipients, and retention period.

John's situation: John could submit a Subject Access Request (SAR) to Telemate to confirm that his email address is on their marketing list and to see what other personal data they hold about him.

3. Right to Object (Article 21) — Most Relevant¶

Data subjects have the absolute right to object to the processing of their personal data for direct marketing purposes. This right is unqualified — Telemate must stop processing for direct marketing immediately upon receiving the objection, without needing to justify it or prove harm.

Under Article 21(2):

"Where personal data are processed for direct marketing purposes, the data subject shall have the right to object at any time to processing of personal data concerning him or her for such marketing, which includes profiling to the extent that it is related to such direct marketing."

John's initial action: John should exercise his right to object under Article 21. He should:

1. Contact Telemate (preferably in writing, via email or a dedicated opt-out form) and clearly state that he objects to the processing of his personal data for direct marketing purposes.
2. Request confirmation that his email address has been removed from all marketing lists.
3. Request confirmation that his data will not be used for any future marketing communications.

4. Right to Erasure / Right to be Forgotten (Article 17)¶

Data subjects can request the deletion of their personal data when:

• The data is no longer necessary for the purpose it was collected.
• The data subject withdraws consent (where consent was the lawful basis).
• The data subject objects to processing (and there is no overriding legitimate interest).
• The data was unlawfully processed.

John's situation: Since John never consented and has now objected, he can request that Telemate erase his email address and any associated personal data from their marketing lists.

5. Right to Withdraw Consent (Article 7(3))¶

If Telemate claims consent as the lawful basis, John can withdraw that consent at any time. Withdrawal must be as easy as giving consent, and withdrawal does not affect the lawfulness of processing before withdrawal.

John's Initial Action — Summary¶

1. Exercise the right to object under Article 21 (direct marketing objection) — this is the most powerful and immediately applicable right.
2. Request erasure under Article 17 of his data from marketing lists.
3. Optionally, submit a Subject Access Request under Article 15 to confirm what data Telemate holds.
4. Document the request (keep a copy of the email/letter) for evidence if escalation is needed.

Marks Breakdown (8 marks)¶

(ii) Responsibility at Telemate [8 marks]¶

Who Is Responsible?¶

Under GDPR, responsibility for data protection is distributed across several roles. In Telemate's case:

1. Data Controller — Primary Responsibility¶

The data controller is the entity that determines the purposes and means of processing personal data (Article 4(7)). Helen, as the marketing manager who composed the email and instructed Tom to send it, is acting on behalf of Telemate (the controller). Telemate as an organisation is the data controller and bears primary legal responsibility for GDPR compliance.

Under Article 24:

"Taking into account the nature, scope and purposes of processing as well as the risks... the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation."

2. Data Protection Officer (DPO) — Advisory and Oversight Role¶

If Telemate has appointed a Data Protection Officer (Article 37), the DPO is responsible for:

• Monitoring GDPR compliance.
• Advising the controller on data protection obligations.
• Acting as a contact point for data subjects and supervisory authorities.
• Conducting Data Protection Impact Assessments (DPIAs) where required.

However, the DPO does not bear direct operational responsibility — they advise and monitor. The controller (Telemate) remains legally responsible.

3. Helen — Marketing Manager (Data Controller Representative)¶

Helen, as the marketing manager who:

• Decided to send the marketing email.
• Instructed Tom to send it to all customers on the email list.
• Did not verify that consent had been obtained.

Helen is acting as an agent of the data controller. While Telemate (the organisation) is the legally responsible entity, Helen may face disciplinary action or individual liability under national law (e.g., the Data Protection Act 2018) if she acted negligently or deliberately bypassed compliance procedures. Note: GDPR fines under Article 83 apply to the controller/processor (Telemate), not individual employees.

4. Tom — Employee (Data Processor Acting on Instructions)¶

Tom, as the employee who sent the emails, is acting under instructions from Helen. He is not the data controller or processor. His role was operational execution of a directive from his manager. Under GDPR, individual criminal liability for employees is a matter of national law (e.g., the Data Protection Act 2018 in Ireland), not the GDPR directly. Tom's primary protection is that he was following instructions from his manager who determined the processing purpose.

5. Senior Management / Board¶

Under GDPR, senior management is expected to ensure that appropriate data protection policies, procedures, and training are in place. Failure to establish a culture of compliance can lead to aggravated fines (Article 83(2)(d): "failure to implement technical and organisational measures").

Summary of Responsibility¶

Marks Breakdown (8 marks)¶

(iii) Escalation and Repercussions [9 marks]¶

John's Actions After Dissatisfaction¶

Despite John exercising his right to object (Article 21) and receiving a second marketing email 6 weeks later, Telemate has:

1. Failed to comply with his Article 21 objection.
2. Continued unlawful processing of his personal data for direct marketing.
3. Demonstrated a pattern of non-compliance, suggesting systemic GDPR failures.

John's Escalation Steps¶

Step 1: Formal Complaint to the Data Protection Commission (DPC)

In Ireland, the supervisory authority is the Data Protection Commission (DPC). Under Article 77, every data subject has the right to lodge a complaint with a supervisory authority, particularly in the EU member state of their habitual residence.

John should submit a formal complaint to the Irish DPC, including:

• Details of the original marketing email.
• Evidence of his objection (copy of the email/letter sent to Telemate).
• Evidence of the second marketing email received 6 weeks later.
• Confirmation that Telemate failed to respond or comply.

The DPC is required under Article 55 to investigate the complaint and take appropriate enforcement action.

Step 2: Right to Compensation (Article 82)

Under Article 82, John has the right to receive compensation from the controller (Telemate) for material or non-material damage (e.g., distress) resulting from a GDPR infringement. John can:

• File a civil claim against Telemate in the Irish courts.
• Claim damages for the distress and inconvenience caused by receiving unwanted marketing emails despite his objection.
• Note: Irish courts have recognised that even minor GDPR violations can give rise to non-material damages for distress (see Pfleiderer v. Bundesrepublik Deutschland and subsequent Irish case law).

Step 3: Right to an Effective Judicial Remedy (Article 79)

John can bring a legal action against Telemate in the Irish courts to enforce his GDPR rights, independent of any complaint to the DPC.

Possible Repercussions for Telemate¶

The DPC has four categories of enforcement powers (Article 58):

1. Corrective Powers (Article 58(2))¶

• Warning: A formal warning to Telemate that its processing operations are infringing the GDPR.
• Reprimand: A formal reprimand for non-compliant processing.
• Order to comply: An order to bring processing operations into compliance (e.g., "remove all data of data subjects who have objected within 24 hours").
• Order to rectify/erase/destroy: An order to erase John's data and any other improperly processed data.
• Temporary or definitive limitation on processing: An order to suspend data processing entirely.
• Suspension of data flows: An order to suspend data transfers to third countries.

2. Administrative Fines (Article 83)¶

GDPR fines are tiered:

John's case falls under the upper tier because it involves violations of:

• Article 6 (lawful basis for processing — no consent obtained).
• Article 21 (right to object to direct marketing).
• Article 5(1)(a) (lawfulness, fairness, and transparency).

The DPC will consider the following aggravating and mitigating factors (Article 83(2)):

• Aggravating: The second email after John's objection demonstrates deliberate or repeated non-compliance. This is a significant aggravating factor that would push the fine toward the upper end of the range.
• Mitigating: If Telemate cooperates with the investigation and takes corrective action, this could reduce the fine.
• Nature, gravity, and duration: The violation is relatively minor in terms of harm (unwanted emails), but the deliberate continuation after objection is serious.

3. Authorisation and Advisory Powers (Article 58(1))¶

• The DPC can advise the controller on required measures.
• The DPC can issue opinions and approve codes of conduct.

4. Certification Powers (Article 58(3))¶

• The DPC can withdraw certifications or impose temporary bans.

Additional Consequences for Telemate¶

• Reputational damage: Public enforcement actions are published by the DPC and widely reported.
• Civil litigation: John and potentially other affected customers could bring class action claims for compensation.
• Increased regulatory scrutiny: A fine for one violation may trigger investigations into other processing activities.
• Mandatory compliance audits: The DPC may require Telemate to undergo independent GDPR compliance audits.

Marks Breakdown (9 marks)¶

Summary of Mark Allocation¶