2024¶

Question 1 [25 marks] — Library Loan System ER Diagram¶

Provide a possible Entity–Relationship diagram that could have been used to produce the relational database schema above. State any assumptions you make.

Note: The exam references "the schema below" for Question 1, but the relational schema itself was not included in the exam paper text. The following answer provides a complete, self-consistent ER diagram for a typical library loan system, demonstrating the modelling conventions expected at this level. In an exam, the schema would have been provided; the methodology shown here applies to any given relational schema.

Approach: Reverse-Engineering an ER Diagram from a Relational Schema¶

When converting from an ER diagram to a relational schema, the following standard mapping rules apply:

Typical Library Loan System ER Diagram¶

A standard library loan system comprises the following entities and relationships:

Entities and Attributes¶

Multivalued Attributes¶

Book.authors — A book can have multiple authors, and an author can write multiple books. This is modelled as a multivalued attribute on Book (shown as a double oval in ER notation), which maps to a separate junction table Book_Author(ISBN, authorID) in the relational schema.

Alternatively, this can be modelled as an M:N relationship between Book and Author, which is semantically equivalent.

Weak Entities¶

Copy is a weak entity dependent on Book:

• A book copy is identified by its copyID in combination with the ISBN of the book it belongs to.
• The identifying relationship is OwnedBy (Book 1:N Copy).
• In the relational schema, the Copy table's PK would be (ISBN, copyID), and ISBN would be a FK to Book.

Fine could also be modelled as a weak entity dependent on Loan:

• A fine exists only in the context of a specific loan.
• Identified by (loanID, fineID) where fineID is the partial key.

Specialisation / Generalisation¶

Member ⊃ StudentMember, StaffMember

This is a partial, disjoint specialisation:

• Partial: Not every member is exclusively a student or staff member — some members may be neither (e.g., external members).
• Disjoint: A member cannot simultaneously be both a student member and a staff member (in the standard model).

StudentMember adds: studentID, faculty. StaffMember adds: staffID, department.

Relationships¶

ER Diagram (Textual Representation)¶

┌──────────────────┐
│     Member       │
├──────────────────┤
│ *memberID        │
│   firstName      │
│   lastName       │
│   address        │
│   phone          │
│   membershipDate │
│   status         │
└────────┬─────────┘
         │ 1
         │ Borrows (partial)
         │ N
         ▼
┌──────────────────┐     ┌──────────────────┐
│      Loan        │────▶│      Fine        │
├──────────────────┤     │    (weak)        │
│ *loanID          │     ├──────────────────┤
│   loanDate       │     │ *fineID          │
│   dueDate        │     │   fineAmount     │
│   returnDate     │     │   issueDate      │
│   fineAmount     │     │ *loanID (FK)     │
└────────┬─────────┘     └──────────────────┘
         │
         │ Member (partial)
         │ N : 1
         ▼
┌──────────────────┐
│     Branch       │
├──────────────────┤
│ *branchID        │
│   branchName     │
│   location       │
│   phone          │
└────────┬─────────┘
         │ 1
         │ Contains (total)
         │ N
         ▼
┌──────────────────┐
│      Copy        │
│    (weak entity) │
├──────────────────┤
│ *copyID          │
│   shelfLocation  │
│ *ISBN (FK)       │
└────────┬─────────┘
         │
         │ OwnedBy (total)
         │ N : 1
         ▼
┌──────────────────┐
│      Book        │
├──────────────────┤
│ *ISBN            │
│   title          │
│   publicationYr  │
│   publisher      │
│   numCopies      │
└────────┬─────────┘
         │
    WrittenBy (M:N)
         │
    ┌────┴────┐
    │         │
    ▼         ▼
┌────────┐ ┌──────────┐
│ Author │ │ (Author) │
├────────┤ ├──────────┤
│*authorID│ │ *authorID │
│  name   │ │   name   │
└────────┘ └──────────┘

Also: Branch ──Keeps(M:N)── Book

Specialisation:
┌──────────────────┐
│     Member       │
│   (superclass)   │
└────────┬─────────┘
         │ o,p (partial, disjoint)
    ┌────┴────┐
    │         │
    ▼         ▼
┌──────────┐ ┌──────────┐
│Student   │ │  Staff   │
│ Member   │ │  Member  │
├──────────┤ ├──────────┤
│ *memberID│ │ *memberID│
│ faculty  │ │ department│
│studentID │ │ staffID  │
└──────────┘ └──────────┘

Assumptions Made¶

1. A book can have multiple authors — modelled as M:N relationship. Each author can write multiple books.

2. A library branch holds multiple copies of the same book — the Copy entity is necessary because the number of copies of a book available for loan is tracked per branch.

3. Loans are tracked with due dates and return dates — these are relationship attributes on the Borrows relationship (or equivalently, attributes of the Loan entity).

4. Fines are generated per loan — modelled as a weak entity dependent on Loan, since a fine cannot exist without an associated loan.

5. Members are either students or staff (or neither) — partial, disjoint specialisation. This is a common assumption in academic library systems.

6. Each book copy belongs to exactly one branch — total participation of Copy in the Contains relationship.

7. A loan record is created only when a member borrows a book — total participation of Loan in Borrows.

8. The numCopies attribute on Book represents the total copies across all branches — an alternative would be to track copies per branch, which is what the Contains relationship does.

9. Status on Member indicates whether the member is active, suspended, or expired — this is a business rule attribute.

10. The relational schema would map as follows:

    • Member(memberID PK, firstName, lastName, address, phone, membershipDate, status)
    • Book(ISBN PK, title, publicationYear, publisher)
    • Author(authorID PK, name)
    • Book_Author(ISBN FK, authorID FK, PK: (ISBN, authorID))
    • Branch(branchID PK, branchName, location, phone)
    • Copy(ISBN FK, copyID, shelfLocation, branchID, PK: (ISBN, copyID), FK: ISBN REFERENCES Book, branchID REFERENCES Branch(branchID))
    • Loan(loanID PK, memberID FK, copyISBN FK, copyID FK, branchID FK, loanDate, dueDate, returnDate, fineAmount)
    • Fine(fineID, fineAmount, issueDate, loanID FK, PK: (loanID, fineID))
    • StudentMember(memberID FK PK REFERENCES Member, faculty, studentID)
    • StaffMember(memberID FK PK REFERENCES Member, department, staffID)

Key ER Notation Used¶

• Rectangles = entities
• Ovals = attributes (underlined for primary keys)
• Diamonds = relationships
• Double rectangle = weak entity (Copy, Fine)
• Double oval = multivalued attribute (Book.authors, if modelled as such)
• Double line = total participation
• Single line = partial participation
• Circle with d = disjoint constraint on specialisation
• Circle with o = overlapping constraint (used if overlapping)
• Dashed line = partial participation on the connecting side

Question 2 [25 marks] — Integrity Constraints¶

(a) [5 marks] Insert into EMPLOYEE¶

Operation: Insert <'Sophia', 'M', 'Wood', '973442298', '1974-05-21', '23 S Lamar Blvd. Rd, Austin, TX', 'F', 62000, '222445555', 5> into EMPLOYEE.

Integrity Constraints Violated¶

1. Entity Integrity Constraint — NOT VIOLATED

The SSN attribute '973442298' is the primary key of EMPLOYEE. Entity integrity requires that primary key attributes be NOT NULL and unique. The value '973442298' is non-null. Checking the existing data, no employee currently has SSN '973442298', so the uniqueness requirement is satisfied. No violation — this constraint is upheld.

2. Referential Integrity Constraint (SUPERSSN → EMPLOYEE(SSN)) — VIOLATED

The SUPERSSN attribute is a foreign key referencing EMPLOYEE(SSN). The value '222445555' is being inserted as the supervisor SSN. Checking all existing SSN values in the EMPLOYEE table:

The value '222445555' does not match any existing SSN in the EMPLOYEE table. Therefore, the referential integrity constraint is violated.

3. Referential Integrity Constraint (DNO → DEPARTMENT(DNUMBER)) — VIOLATED

The DNO attribute is a foreign key referencing DEPARTMENT(DNUMBER). The value 5 is being inserted. Checking existing DNUMBER values in DEPARTMENT:

The value 5 does exist (Research department). No violation — this constraint is upheld.

4. Domain Constraints — NOT VIOLATED

All attribute values are within their declared domains: VARCHAR strings are non-empty, CHAR(9) has exactly 9 characters, DATE is valid, CHAR(1) is a single character, and DECIMAL is a positive number.

Ways to Enforce These Constraints¶

For the SUPERSSN referential integrity violation:

(b) [5 marks] Insert into DEPARTMENT¶

Operation: Insert <'Information Technology', 2, '987987987', '2007-10-01'> into DEPARTMENT.

Integrity Constraints Violated¶

1. Entity Integrity Constraint — NOT VIOLATED

The DNUMBER attribute (value 2) is the primary key. It is non-null and 2 does not currently exist in DEPARTMENT (existing values are 1, 4, 5). The DNAME value 'Information Technology' is also non-null. No violation.

2. Referential Integrity Constraint (MGRSSN → EMPLOYEE(SSN)) — VIOLATED

The MGRSSN attribute is a foreign key referencing EMPLOYEE(SSN). The value '987987987' is being inserted. Checking all existing SSN values:

The value '987987987' does not correspond to any existing employee. Referential integrity is violated.

3. Referential Integrity Constraint (DNUMBER → DEPT_LOCATIONS) — POTENTIALLY VIOLATED

If DEPT_LOCATIONS.DNUMBER has a foreign key referencing DEPARTMENT.DNUMBER with ON UPDATE CASCADE or ON DELETE CASCADE constraints, inserting a department with DNUMBER = 2 does not itself violate any constraint (there are no existing DEPT_LOCATIONS rows with DNUMBER = 2 to conflict with). However, if there were existing DEPT_LOCATIONS rows referencing DNUMBER = 2, this would be a problem — but there are none. No violation in the current state.

4. Domain Constraints — NOT VIOLATED

All values are within their declared domains. DATE '2007-10-01' is valid. VARCHAR values are appropriate.

Ways to Enforce These Constraints¶

For the MGRSSN referential integrity violation:

Additional consideration: The insert should ideally be preceded by an insert into EMPLOYEE for the manager '987987987', or an existing employee's SSN should be used.

© [5 marks] Insert into WORKS_ON¶

Operation: Insert <'777624972', 15, '40.0'> into WORKS_ON.

Integrity Constraints Violated¶

1. Entity Integrity Constraint — NOT VIOLATED

The composite primary key of WORKS_ON is (ESSN, PNO). The proposed values are ESSN = '777624972' and PNO = 15. Checking existing WORKS_ON rows:

The pair ('777624972', 15) does not exist. No violation.

2. Referential Integrity Constraint (ESSN → EMPLOYEE(SSN)) — VIOLATED

The ESSN attribute is a foreign key referencing EMPLOYEE(SSN). The value '777624972' is being inserted. Checking all existing SSN values:

The value '777624972' does not correspond to any employee. Referential integrity is violated.

3. Referential Integrity Constraint (PNO → PROJECT(PNUMBER)) — VIOLATED

The PNO attribute is a foreign key referencing PROJECT(PNUMBER). The value 15 is being inserted. Checking existing PNUMBER values:

The value 15 does not correspond to any project. Referential integrity is violated.

4. Domain Constraints — NOT VIOLATED

HOURS is declared as DECIMAL(3,1), meaning up to 3 digits with 1 decimal place. The value 40.0 fits within this domain (range: 0.0 to 999.9). No violation.

Ways to Enforce These Constraints¶

For both referential integrity violations:

Key point: Because ESSN and PNO are both part of the primary key, SET NULL is not a viable enforcement option. The only practical enforcement is to reject the insert and require the caller to first ensure the referenced employee and project records exist.

(d) [5 marks] Delete DEPARTMENT tuples with DNUMBER = 5¶

Operation: Delete all rows from DEPARTMENT where DNUMBER = 5.

Integrity Constraints Violated¶

1. Referential Integrity Constraints — VIOLATED (multiple)

Deleting the department with DNUMBER = 5 (Research) violates referential integrity in three tables that reference DEPARTMENT:

Three referential integrity violations are triggered.

Ways to Enforce These Constraints¶

Recommended approach: Use RESTRICT (or NO ACTION) to prevent accidental data loss. The administrator should manually:

1. Reassign the 3 employees to another department.
2. Reassign the 3 projects to another department.
3. Move the department location or merge it.
4. Then perform the delete.

(e) [5 marks] Modify PROJECT.PNUMBER from 30 to 40¶

Operation: Update the PNUMBER attribute of the PROJECT tuple with PNUMBER = 30 to 40.

Integrity Constraints Violated¶

1. Entity Integrity Constraint (Primary Key Uniqueness) — VIOLATED

The PNUMBER attribute is the primary key of PROJECT. Updating PNUMBER from 30 to 40 would create a duplicate primary key value because another project already has PNUMBER = 40 (Project 'ProductZ').

After the update, both ProductZ and Newbenefits would have PNUMBER = 40, violating the uniqueness constraint on the primary key. Entity integrity is violated.

2. Referential Integrity Constraint (WORKS_ON.PNO → PROJECT.PNUMBER) — VIOLATED

The WORKS_ON.PNO attribute is a foreign key referencing PROJECT(PNUMBER). The tuple with PNUMBER = 30 has two referencing rows in WORKS_ON:

If PNUMBER = 30 is changed to 40 in PROJECT, these WORKS_ON rows would reference a non-existent project number (the old 30 is gone; the new value 40 already exists as a different project). This creates an orphan reference — referential integrity is violated.

3. Referential Integrity Constraint (PROJECT.DNUM → DEPARTMENT.DNUMBER) — NOT VIOLATED

The DNUM attribute is a FK to DEPARTMENT(DNUMBER). This is not being modified, so no violation here.

Ways to Enforce These Constraints¶

For the primary key uniqueness violation:

For the referential integrity violation (WORKS_ON.PNO → PROJECT.PNUMBER):

Recommended approach: The update should be rejected. If the intent is to rename the project (change from Newbenefits to a different identity), the correct approach would be:

1. First, reassign the WORKS_ON references from PNO = 30 to a new, unique project number.
2. Then, perform the update on PROJECT.PNUMBER.
3. Alternatively, if the intent is simply to change the project identity, use a non-key attribute (like PNAME) instead of modifying the primary key.

Question 3 [25 marks] — SQL Privilege Grants¶

Suppose that all the relations were created by (and hence are owned by) user X, who wants to grant the following privileges to user accounts A, B, C, D, and E.

(a) [5 marks] Account A¶

Requirement: Account A can retrieve or modify any relation except DEPENDENT and can grant any of these privileges to other users.

SQL Statements¶

-- Grant SELECT and INSERT, UPDATE, DELETE on EMPLOYEE to A, with GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE ON EMPLOYEE TO A WITH GRANT OPTION;

-- Grant SELECT and INSERT, UPDATE, DELETE on DEPARTMENT to A, with GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE ON DEPARTMENT TO A WITH GRANT OPTION;

-- Grant SELECT and INSERT, UPDATE, DELETE on DEPT_LOCATIONS to A, with GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE ON DEPT_LOCATIONS TO A WITH GRANT OPTION;

-- Grant SELECT and INSERT, UPDATE, DELETE on PROJECT to A, with GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE ON PROJECT TO A WITH GRANT OPTION;

-- Grant SELECT and INSERT, UPDATE, DELETE on WORKS_ON to A, with GRANT OPTION
GRANT SELECT, INSERT, UPDATE, DELETE ON WORKS_ON TO A WITH GRANT OPTION;

DEPENDENT is explicitly excluded — no GRANT statement is issued for it.

Explanation¶

• SELECT covers the "retrieve" requirement.
• INSERT, UPDATE, DELETE cover the "modify" requirement. (In SQL, "modify" encompasses all DML write operations.)
• WITH GRANT OPTION allows A to further grant any of these privileges to other users, satisfying the delegation requirement.
• The privileges are granted per relation because SQL's GRANT statement operates on a single relation at a time. There is no "all relations except X" syntax.
• DEPENDENT is deliberately omitted from all GRANT statements, so A has no access to it.

Alternative: Using a Role¶

In systems that support roles, this could be cleaner:

CREATE ROLE full_access_role;
GRANT SELECT, INSERT, UPDATE, DELETE ON EMPLOYEE TO full_access_role WITH GRANT OPTION;
GRANT SELECT, INSERT, UPDATE, DELETE ON DEPARTMENT TO full_access_role WITH GRANT OPTION;
GRANT SELECT, INSERT, UPDATE, DELETE ON DEPT_LOCATIONS TO full_access_role WITH GRANT OPTION;
GRANT SELECT, INSERT, UPDATE, DELETE ON PROJECT TO full_access_role WITH GRANT OPTION;
GRANT SELECT, INSERT, UPDATE, DELETE ON WORKS_ON TO full_access_role WITH GRANT OPTION;
GRANT full_access_role TO A;

This approach centralises privilege management and makes it easier to add or remove relations.

(b) [5 marks] Account B¶

Requirement: Account B can retrieve all attributes of EMPLOYEE and DEPARTMENT except SALARY, MGRSSN, and MGRSTARTDATE.

SQL Statements¶

-- B can SELECT specific columns from EMPLOYEE (all except SALARY)
GRANT SELECT (FNAME, MINIT, LNAME, SSN, BDATE, ADDRESS, SEX, SUPERSSN, DNO)
    ON EMPLOYEE TO B;

-- B can SELECT specific columns from DEPARTMENT (all except MGRSSN, MGRSTARTDATE)
GRANT SELECT (DNAME, DNUMBER)
    ON DEPARTMENT TO B;

Explanation¶

• Column-level privileges are used here. SQL allows granting SELECT on a subset of columns, which is exactly what is needed to exclude sensitive attributes.
• SALARY is excluded from EMPLOYEE — this is a common security requirement to protect employee compensation data.
• MGRSSN and MGRSTARTDATE are excluded from DEPARTMENT — these identify the department manager and their start date, which may be sensitive organisational information.
• Note: SUPERSSN is not excluded (it references an employee's supervisor SSN). If the intent were to also hide this, it would need to be listed in the exclusion. The question only excludes SALARY, MGRSSN, and MGRSTARTDATE.
• WITH GRANT OPTION is NOT included — B can read but cannot grant privileges to others.

© [5 marks] Account C¶

Requirement: Account C can retrieve or modify WORKS_ON but can only retrieve the FNAME, MINIT, LNAME, SSN attributes of EMPLOYEE and the PNAME, PNUMBER attributes of PROJECT.

SQL Statements¶

-- C can fully modify WORKS_ON (SELECT, INSERT, UPDATE, DELETE)
GRANT SELECT, INSERT, UPDATE, DELETE ON WORKS_ON TO C;

-- C can SELECT specific columns from EMPLOYEE
GRANT SELECT (FNAME, MINIT, LNAME, SSN)
    ON EMPLOYEE TO C;

-- C can SELECT specific columns from PROJECT
GRANT SELECT (PNAME, PNUMBER)
    ON PROJECT TO C;

Explanation¶

• WORKS_ON receives full DML privileges (SELECT, INSERT, UPDATE, DELETE) — "retrieve or modify" means all access types.
• EMPLOYEE receives column-restricted SELECT — only the four specified attributes (FNAME, MINIT, LNAME, SSN) are accessible. This is the minimum information needed to identify an employee without exposing sensitive data like salary, address, or supervisor.
• PROJECT receives column-restricted SELECT — only PNAME and PNUMBER are accessible. This allows C to identify projects without seeing their location or department assignment.
• No WITH GRANT OPTION — C cannot delegate these privileges.
• DEPARTMENT and DEPT_LOCATIONS are not mentioned, so C has no access to them.

(d) [5 marks] Account D¶

Requirement: Account D can retrieve any attribute of EMPLOYEE or DEPENDENT and can modify DEPENDENT.

SQL Statements¶

-- D can SELECT all attributes of EMPLOYEE
GRANT SELECT ON EMPLOYEE TO D;

-- D can SELECT all attributes of DEPENDENT
GRANT SELECT ON DEPENDENT TO D;

-- D can INSERT, UPDATE, DELETE on DEPENDENT (modify)
GRANT INSERT, UPDATE, DELETE ON DEPENDENT TO D;

Explanation¶

• EMPLOYEE receives SELECT only — "retrieve any attribute" means full SELECT access on all columns. No WITH GRANT OPTION.
• DEPENDENT receives SELECT (for "retrieve any attribute") plus INSERT, UPDATE, DELETE (for "can modify").
• "Retrieve or modify" on DEPENDENT means D needs both read and write access. The SELECT covers retrieval; INSERT, UPDATE, DELETE cover modification.
• DEPARTMENT, DEPT_LOCATIONS, PROJECT, and WORKS_ON are not mentioned, so D has no access to them.
• WITH GRANT OPTION is NOT included — D cannot grant privileges to others.

(e) [5 marks] Account E¶

Requirement: Account E can retrieve any attribute of EMPLOYEE but only for EMPLOYEE tuples that have DNO = 3.

SQL Statements¶

-- Create a view that filters EMPLOYEE rows to DNO = 3
CREATE VIEW EMP_DEPT_3 AS
    SELECT * FROM EMPLOYEE
    WHERE DNO = 3;

-- Grant SELECT on the view to E
GRANT SELECT ON EMP_DEPT_3 TO E;

Explanation¶

• Row-level filtering in SQL is achieved through views. There is no native SQL syntax for granting SELECT on a table with a WHERE clause condition directly in the GRANT statement.
• The view EMP_DEPT_3 acts as a virtual table that only exposes rows where DNO = 3. When E queries SELECT * FROM EMP_DEPT_3, the DBMS transparently applies the filter.
• E can retrieve any attribute through the view (SELECT *), which is equivalent to having SELECT on all columns of EMPLOYEE, but restricted to the subset of rows matching the condition.
• E cannot INSERT, UPDATE, or DELETE through the view (unless these are explicitly granted with appropriate conditions), so E is read-only on this data.

Important Considerations¶

1. The owner X must have SELECT privilege on EMPLOYEE (which is guaranteed since X created the table).

2. Dynamic WHERE clauses: If the department number changes (e.g., from 3 to 4), the view definition must be dropped and recreated. This is a limitation of the view-based approach.

3. Alternative — Grant SELECT with a check: Some DBMS support views with WITH CHECK OPTION for updatable views, but for a read-only grant, the simple view is sufficient.

4. Security note: If E is later granted direct SELECT on EMPLOYEE, the row-level restriction is bypassed. The view-based approach only works if E does not have direct table access.

5. Column-level + row-level: If both column and row restrictions were needed, the view could specify columns explicitly:

   CREATE VIEW EMP_DEPT_3 AS
       SELECT FNAME, LNAME, SSN, DNO FROM EMPLOYEE WHERE DNO = 3;
   GRANT SELECT ON EMP_DEPT_3 TO E;
   

Question 4 [25 marks] — GDPR¶

(i) [8 marks] What is GDPR?¶

Definition¶

The General Data Protection Regulation (GDPR) is Regulation (EU) 2016/679, a comprehensive data protection and privacy regulation enacted by the European Union. It came into force on 25 May 2018 and establishes a unified data protection framework for all EU member states.

The GDPR is designed to:

1. Harmonise data protection laws across the European Union.
2. Empower data subjects (individuals) with greater control over their personal data.
3. Impose stringent obligations on data controllers and processors.
4. Standardise data protection enforcement across EU jurisdictions.

Jurisdiction GDPR Applies To¶

The GDPR applies based on the scope provisions in Articles 3 and 4:

1. Territorial Scope — Article 3(1): Establishment Criterion

The GDPR applies to any controller or processor established in the EU, regardless of where the data processing takes place. This covers:

• Companies registered in an EU member state.
• Branches or subsidiaries of non-EU companies operating within the EU.
• Organisations with a "real and effective" activity in the EU, even if registered elsewhere.

2. Territorial Scope — Article 3(2): Targeting Criterion (Extra-Territorial Application)

The GDPR applies to controllers or processors not established in the EU when their processing activities relate to:

• Offering goods or services (paid or free) to data subjects in the EU. This applies even if no payment is made. Indicators include: EU language/currency, EU customer options, delivery to the EU.
• Monitoring the behaviour of data subjects in the EU. This includes tracking online behaviour through cookies, profiling, and analytics to create user profiles.

Practical Impact: A company based in the United States, Australia, or any non-EU country must comply with the GDPR if it:

• Has an establishment (office, subsidiary) in the EU.
• Offers products/services to EU residents.
• Monitors the behaviour of EU residents.

Failure to comply can result in fines of up to €20 million or 4% of global annual turnover (whichever is higher) under Article 83.

Legislation GDPR Replaces¶

The GDPR replaced the Data Protection Directive 95/46/EC (formally: Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data), commonly known as the 1995 Data Protection Directive or the WPDD (Working Party Data Protection Directive).

Key Differences Between the Directive and the Regulation:

The transition from Directive to Regulation was specifically designed to eliminate the "transposition gap" — the period during which member states had to enact national legislation, during which compliance was uncertain and enforcement was inconsistent.

(ii) [8 marks] List the GDPR Principles¶

The GDPR principles are set out in Article 5(1) of the regulation. There are seven core principles for the processing of personal data, each accompanied by a compliance requirement in Article 5(2):

1. Lawfulness, Fairness and Transparency (Article 5(1)(a))¶

Personal data must be:

• Lawful: Processed on at least one of the six lawful bases specified in Article 6(1) (consent, contract, legal obligation, vital interests, public task, legitimate interests).
• Fair: Not processed in a way that is unjust, deceptive, or unduly detrimental to the data subject. The processing must not mislead or cause unreasonable harm.
• Transparent: Data subjects must be clearly informed about how their data is processed. This is operationalised through the privacy notice requirements in Articles 13 and 14.

2. Purpose Limitation (Article 5(1)(b))¶

Personal data must be:

• Collected for specified, explicit, and legitimate purposes — the purpose must be clearly defined at the point of collection.
• Not further processed in a manner incompatible with those purposes — secondary processing must be compatible with the original purpose. Compatibility is assessed by considering the relationship between purposes, the context of collection, the nature of the data, and the data subject's expectations.

Permitted secondary processing (under Article 5(1)(b) second sentence):

• Processing for archiving purposes in the public interest.
• Processing for scientific or historical research purposes.
• Processing for statistical purposes.

3. Data Minimisation (Article 5(1)©)¶

Personal data must be:

• Adequate, relevant, and limited to what is necessary in relation to the purposes for which they are processed.
• Only data that is strictly needed for the stated purpose should be collected and retained.
• This means collecting the minimum amount of data required to achieve the purpose — no "just in case" data collection.

Example: A newsletter signup should only collect email address and name — not date of birth, gender, or address unless those are genuinely necessary for the service.

4. Accuracy (Article 5(1)(d))¶

Personal data must be:

• Accurate and, where necessary, kept up to date.
• Every reasonable step must be taken to ensure that inaccurate data is erased or rectified without delay.
• The data controller bears the burden of ensuring data quality. Inaccurate data that is not corrected constitutes a breach of this principle.

Operational requirements:

• Mechanisms for data subjects to request correction of inaccurate data (Article 16 — right to rectification).
• Periodic data quality reviews.
• Verification of data at the point of collection.

5. Storage Limitation (Article 5(1)(e))¶

Personal data must be:

• Kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the data is processed.
• Retention periods must be defined and justified.
• Data that is no longer needed must be anonymised or erased.

Key aspects:

• Retention policies must be documented.
• Criteria for determining retention periods must be established (e.g., legal requirements, business needs).
• Anonymised data (where the data subject is no longer identifiable) falls outside the scope of the GDPR.

6. Integrity and Confidentiality (Article 5(1)(f))¶

Personal data must be:

• Processed in a manner that ensures appropriate security, including protection against unauthorised or unlawful processing and against accidental loss, destruction, or damage.
• Appropriate technical and organisational measures must be applied. These include (but are not limited to):
• Encryption and pseudonymisation.
• Confidentiality, integrity, availability, and resilience of processing systems.
• Ability to restore availability and access following a physical or technical incident.
• Regular testing and evaluation of security measures.

This principle is often referred to as "security" and is the basis for the breach notification requirements in Articles 33 and 34.

7. Accountability (Article 5(2))¶

The data controller is responsible for, and must be able to demonstrate compliance with, all of the above six principles.

Operational requirements include:

• Maintaining records of processing activities (Article 30).
• Implementing data protection by design and by default (Article 25).
• Conducting Data Protection Impact Assessments (DPIAs) for high-risk processing (Article 35).
• Appointing a Data Protection Officer where required (Article 37).
• Implementing appropriate data protection policies and procedures.
• Being able to demonstrate compliance to supervisory authorities upon request.

Accountability is both a principle and a meta-principle — it requires the controller to have mechanisms in place to prove compliance with all other principles.

Summary Table¶

(iii) [9 marks] What is Personal Data?¶

Definition¶

Under Article 4(1) of the GDPR, personal data is defined as:

"any information relating to an identified or identifiable natural person (data subject)"

An identifiable natural person is further defined as:

"one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person."

Key Elements of the Definition¶

1. "Any information"

The definition is extremely broad. It covers:

• Structured data (database records, forms, profiles).
• Unstructured data (emails, documents, images, audio recordings).
• Online identifiers (IP addresses, cookie IDs, device fingerprints, MAC addresses, RFID tags).
• Offline identifiers (employee numbers, customer IDs, license plate numbers).
• Subjective data (opinions, assessments, ratings).
• Objective data (salary, medical test results, transaction records).
• Publicly available information — even if data is publicly accessible (e.g., a company directory), it is still personal data if it relates to an identifiable individual.

2. "Relating to"

Information "relates to" a data subject if it:

• Is about the individual (content test) — e.g., a medical record diagnosis.
• Is linked to the individual (connection test) — e.g., a user ID mapped to a name.
• Has relevance to the individual (impact test) — e.g., data used to make decisions about the individual, even if not directly about them.

3. "Identified or Identifiable"

• Identified: The individual is already known (e.g., name is recorded).
• Identifiable: The individual can be identified now or in the future through additional information. This is the critical distinction — data that is not currently identifying but could become identifying is still personal data.

The "identifiability" test considers:

• All means "reasonably likely to be used" by the controller or any other person to identify the individual.
• Factors including the cost and time required for identification.
• Technological developments — data that was anonymised at one point may become identifiable with new technology.
• The context — a dataset that is anonymous in one context may be identifiable in another when combined with other data.

4. "Natural Person"

The GDPR protects living human beings only. It does not apply to:

• Legal persons (companies, organisations, corporations).
• Deceased persons (though member states may have separate rules for data relating to the deceased).
• Anonymous groups (e.g., aggregate statistics about a demographic).

Examples of Personal Data¶

Examples of What is NOT Personal Data¶

Special Categories of Personal Data¶

Under Article 9, certain types of personal data are classified as "special categories" and receive enhanced protection. Processing these is prohibited unless one of the specific exceptions in Article 9(2) applies:

1. Racial or ethnic origin
2. Political opinions
3. Religious or philosophical beliefs
4. Trade union membership
5. Genetic data
6. Biometric data (when used for identification purposes)
7. Health data
8. Data concerning a person's sex life or sexual orientation

Additionally, Article 10 provides enhanced protection for data relating to criminal convictions and offences, which may only be processed under official authority or where authorised by EU or member state law.

Pseudonymisation vs Anonymisation¶

Critical point: Pseudonymised data is still personal data under the GDPR. It is a security measure (encouraged under Article 25) but does not remove the data from the regulation's scope. Only true anonymisation — where re-identification is not reasonably possible — takes data outside the GDPR.

The "Reasonably Likely" Test¶

The GDPR's definition of identifiability uses the standard of "reasonably likely" means being used to identify the individual. This is a contextual assessment that considers:

1. Who might attempt identification? The controller, but also any third party with access to the data.
2. What means are available? All technical, organisational, and financial resources available to the identifier.
3. What is the cost and time? If identification requires disproportionate effort, the data may not be "identifiable."
4. Are there legal, technical, or financial measures? If the controller has implemented measures to prevent identification (e.g., access controls, encryption), this is considered in the assessment.
5. Technological progress? The assessment must account for the possibility that future technology could enable identification.

This "reasonably likely" standard ensures that the GDPR's protections are forward-looking and technology-neutral — data that appears anonymous today may become identifiable tomorrow, and the GDPR must account for that possibility.