OCR A-Level Computer Science: Databases, Ethics & Law — Complete Revision Guide (H446)
OCR A-Level Computer Science: Databases, Ethics & Law — Complete Revision Guide
This course pairs two strands that the rest of computer science assumes but rarely states: how we store structured data reliably, and what the law and our professional ethics demand of us once we hold it. The H446 specification draws the database material from section 1.3.2 and the legal, moral and ethical material from section 1.5, and the examiners treat them as complementary — a database is exactly the kind of system that the Data Protection Act, the Computer Misuse Act and the wider ethics of computing exist to govern. Getting full marks here means being equally comfortable normalising a table to third normal form and explaining why a developer who exceeds their authorised access has broken the law.
All of this material is examined in Component 01 (Computer systems), the written paper covering the 1.x sections of the specification. The database half rewards technical precision — correct SQL, correct normal forms, correct reasoning about transactions — while the ethics-and-law half rewards balanced, well-structured argument, the ability to weigh competing stakeholder interests and reach a justified position. These are different exam skills wearing the same course, and strong candidates prepare for both deliberately. The database knowledge also connects straight back to the data-structures course (a table is an array of records; an index is often a tree or hash table) and to the networks course (every web application is a client–server database deployment, and SQL injection is a network-security threat aimed squarely at the database).
This is Course 8 of 11 on the LearningBro OCR A-Level Computer Science learning path. The course, OCR A-Level CS: Databases, Ethics & Law, works through relational database concepts, normalisation and SQL, then transaction processing and big data, before turning to the four pillars of UK computing law and the broader ethical and environmental questions the discipline must face. By the end you should be able to design and query a normalised relational database and to construct a reasoned argument about the legal and ethical use of computer systems.
Guide Overview
This course is a ten-lesson sequence that runs from relational theory and SQL into the legal and ethical framework that governs data. Work through them in order — the SQL lessons assume the relational concepts, and the law lessons build a cumulative framework.
- Database Concepts
- Normalisation
- SQL Fundamentals
- SQL Joins
- Transaction Processing
- Big Data
- Data Protection Act
- Computer Misuse Act
- Intellectual Property
- Ethical and Environmental
Database Concepts: The Relational Model
The Database Concepts lesson establishes the vocabulary of the relational model. A relational database organises data into tables (relations), each made of records (rows / tuples) and fields (columns / attributes). Every table needs a primary key — an attribute (or combination of attributes) that uniquely identifies each record — and relationships between tables are created by a foreign key, an attribute in one table that refers to the primary key of another, enforcing referential integrity so that you cannot reference a record that does not exist. You should also know the idea of a composite key (a primary key spanning more than one field) and a secondary key or index used to speed up searches.
This lesson explains why the relational model is preferred over a single flat file: separating data into related tables removes the duplication that causes update, insertion and deletion anomalies, and it lets a Database Management System (DBMS) enforce integrity and control access centrally. You should understand entity relationships — one-to-one, one-to-many and many-to-many — and be able to read or sketch a simple entity-relationship (E-R) diagram, recognising that a many-to-many relationship is resolved in practice by introducing a linking (junction) table. The conceptual thread to carry forward is that a well-designed schema minimises redundancy while preserving the ability to reconstruct any view of the data through relationships — which is precisely what normalisation systematises.
Normalisation: Designing Out Redundancy
The Normalisation lesson is the most technical design skill in the course and a reliable source of marks. Normalisation is the process of organising a database to reduce redundancy and eliminate the update, insertion and deletion anomalies that plague unstructured data, by progressing through a series of normal forms. You must be able to take an unnormalised table and work it up to Third Normal Form (3NF), stating at each step why a rule is or is not satisfied.
| Normal form | Rule | What it removes |
|---|---|---|
| First (1NF) | No repeating groups; each field holds a single atomic value; each record is unique | Repeating groups and multi-valued fields |
| Second (2NF) | In 1NF and every non-key attribute depends on the whole primary key | Partial dependencies on part of a composite key |
| Third (3NF) | In 2NF and no non-key attribute depends on another non-key attribute | Transitive (non-key to non-key) dependencies |
The disciplined way to remember the progression is the well-worn maxim that every non-key attribute must depend on "the key, the whole key, and nothing but the key" — which maps neatly onto 1NF (there is a key and atomic values), 2NF (the whole key, removing partial dependencies) and 3NF (nothing but the key, removing transitive dependencies). For the exam, practise the full worked transformation: identify the repeating groups and split them out for 1NF, identify attributes that depend on only part of a composite key and move them to their own table for 2NF, and identify attributes that depend on another non-key attribute and extract them for 3NF. Be ready, too, to explain the trade-off — normalisation reduces redundancy and protects integrity, but a heavily normalised design needs more joins to answer a query, which is sometimes relaxed (denormalised) deliberately for performance.
SQL Fundamentals: Querying and Modifying Data
The SQL Fundamentals lesson turns the relational model into a working query language. You must be fluent in the core Structured Query Language statements, both for retrieving data and for changing it. The backbone is the SELECT statement with its standard clauses, and you should be able to read and write queries that filter, sort and aggregate.
SELECT FirstName, Surname
FROM Student
WHERE YearGroup = 13
ORDER BY Surname ASC;
Be ready to use WHERE with comparison and logical operators (AND, OR, NOT), pattern matching with LIKE and wildcards, ORDER BY for sorting, and aggregate functions such as COUNT, SUM, AVG, MIN and MAX, often combined with GROUP BY to summarise data by category. You also need the data-manipulation statements that change a database: INSERT INTO ... VALUES ... to add a record, UPDATE ... SET ... WHERE ... to modify existing records, and DELETE FROM ... WHERE ... to remove them. A point examiners reliably reward is awareness that an UPDATE or DELETE without a WHERE clause affects every row in the table — a classic and costly mistake. Practise translating an English requirement ("list the surnames of every Year 13 student in alphabetical order") into correct SQL, because that translation is the exam task.
SQL Joins: Querying Across Tables
The SQL Joins lesson addresses the consequence of normalisation: because data is spread across related tables, answering a real question usually means recombining them. A JOIN retrieves data from two or more tables by matching a foreign key in one to the primary key in another. The form OCR expects you to use confidently is the INNER JOIN, which returns only the rows where the join condition is satisfied — that is, records that have a match in both tables.
SELECT Student.Surname, Class.ClassName
FROM Student
INNER JOIN Class
ON Student.ClassID = Class.ClassID;
You should be able to write a join that links two tables on their key relationship, alias table names for clarity, and combine a join with WHERE, ORDER BY and aggregate clauses to answer a layered question. Understanding why the join is needed is as important as the syntax: it is the operational payoff of normalisation — the schema was split to remove redundancy, and the join puts the pieces back together on demand. You should also appreciate, at least in outline, that other join types exist (such as outer joins that retain unmatched rows), but the INNER JOIN that returns matched records is the one to master for H446. Joins are where the database course connects back to the data-structures course, because the DBMS uses indexes — frequently trees or hash tables — to perform these matches efficiently rather than scanning every row.
Transaction Processing: Keeping Data Consistent
The Transaction Processing lesson addresses what happens when many users hit the same database at once and things can go wrong mid-operation. A transaction is a single logical unit of work — a bank transfer that debits one account and credits another, for example — that must either complete entirely or not at all. The properties OCR expects you to know are the ACID properties:
- Atomicity — the transaction is all-or-nothing; if any part fails, the whole transaction is rolled back.
- Consistency — a transaction takes the database from one valid state to another, never leaving it half-changed.
- Isolation — concurrent transactions do not interfere; each behaves as if it ran alone.
- Durability — once a transaction is committed, its effects survive even a subsequent system failure.
You should understand the mechanisms that deliver these guarantees: record locking, which prevents two transactions from modifying the same data simultaneously (and the deadlock that can arise when two transactions each wait on a record the other holds), commit and rollback, and the transaction log / journal that records changes so the database can be recovered after a crash. The headline example is the bank transfer: without atomicity, a failure between the debit and the credit would destroy money, which is exactly the inconsistency ACID exists to prevent. Be ready to explain how locking enforces isolation and how the log underpins durability and recovery.
Big Data: When Volume, Velocity and Variety Break the Model
The Big Data lesson considers datasets so large or fast-moving that conventional relational tools struggle, conventionally characterised by the "three Vs": volume (the sheer quantity of data), velocity (the speed at which it is generated and must be processed), and variety (the mix of structured, semi-structured and unstructured forms). You should be able to give realistic sources — social media, sensor and IoT streams, transaction records, scientific instruments — and to explain why a single relational server on one machine cannot cope with data at this scale.
This lesson introduces the broad strategies for handling big data: distributed processing that spreads work across many machines so that computation runs in parallel, and functional programming approaches that suit such parallelism because functions without side effects can be evaluated independently and in any order — a neat link to the functional-programming strand of the wider qualification. You should understand the idea of a graph schema / graph database for highly connected data (echoing the graphs from the data-structures course) and recognise that big data raises sharp ethical questions — about privacy, consent and the inferences that can be drawn by combining datasets — which leads naturally into the legal and ethical lessons that follow. Treat big data as the bridge between the technical half of the course and the law-and-ethics half.
Data Protection: The Data Protection Act 2018 and UK GDPR
The Data Protection Act lesson covers the law that governs how organisations handle personal data — information relating to an identifiable living individual. In the UK this is the Data Protection Act 2018, which sits alongside the UK GDPR, and you should know the framework it establishes: a set of data-protection principles requiring, in broad terms, that personal data be processed lawfully, fairly and transparently; collected for specified, legitimate purposes and not used incompatibly; adequate, relevant and limited to what is necessary; accurate and kept up to date; kept no longer than necessary; and held securely. You should also know the roles it defines — the data subject (the individual the data is about), the data controller (who decides why and how data is processed) and the data processor — and the rights it grants data subjects, including the right of access to their data, the right to have inaccurate data corrected, and the right to have data erased in defined circumstances.
For the exam, focus on applying the principles to a scenario rather than reciting them — explaining, for instance, why holding customer data indefinitely or using it for a purpose the customer never agreed to would breach the legislation, and what an organisation must do to comply (limit collection, secure storage, honour access requests). You should also be aware that an independent regulator oversees compliance and can take enforcement action against organisations that fail to protect personal data. This legislation is the direct legal counterpart to the database design and security you studied earlier — the law about why the technical safeguards matter.
Computer Misuse: The Computer Misuse Act 1990
The Computer Misuse Act lesson covers the principal UK law against hacking and the misuse of computer systems, the Computer Misuse Act 1990. You should know that it creates a tiered set of offences, broadly: unauthorised access to computer material (gaining access you are not entitled to, such as logging into another person's account); unauthorised access with intent to commit or facilitate a further offence (for example accessing a system in order to commit fraud); and unauthorised modification of computer material (such as deleting or altering data, or deploying malware). Later amendments added provisions concerning acts intended to impair the operation of a computer (covering denial-of-service-style attacks) and the making or supplying of hacking tools.
The exam skill is to classify a described scenario against these offences — recognising, for instance, that a curious employee who reads files they have no authority to open commits unauthorised access even if they change nothing, while someone who plants ransomware commits unauthorised modification. This lesson is the legal mirror of the network-security threats from Course 7: the malware, phishing, brute-force and DoS attacks you studied as technical threats are, in law, exactly what the Computer Misuse Act criminalises. Being able to map a technical action to the specific offence it constitutes is precisely the connection examiners are looking for.
Intellectual Property: Copyright, Patents and Licensing
The Intellectual Property lesson covers how the law protects creative and inventive work in computing. The central statute is the Copyright, Designs and Patents Act 1988, which automatically protects original works — including software source code, music, images and written content — from being copied or distributed without permission. You should distinguish the main forms of protection: copyright (automatic, protecting the expression of an idea such as the actual code), patents (which can protect a genuinely novel invention or technical method but must be applied for), and trademarks (protecting brand identifiers such as names and logos).
This lesson also covers software licensing and the spectrum from proprietary / closed-source software (where the source code is withheld and use is restricted by licence) to open-source and free software (where the source is published and may be studied, modified and redistributed under licences that set the terms), along with models such as freeware and shareware. You should be able to weigh the trade-offs — open-source software offers transparency, community improvement and no licence cost but may lack guaranteed support, while proprietary software offers vendor support and accountability but at a cost and with restrictions. The connection to the rest of the course is that software is intellectual property, so questions about copying code, reusing libraries or distributing modified programs are legal questions as much as technical ones.
Ethical and Environmental Issues: The Wider Responsibility
The Ethical and Environmental lesson widens the lens from what is legal to what is right, and to the impact of computing on the world. The examiners expect a balanced, multi-stakeholder argument rather than a one-sided opinion, so you should be able to set out the competing considerations around the big ethical themes: privacy and surveillance (the tension between security or convenience and individual liberty), automation and employment (the productivity gains of automation against the displacement of workers), algorithmic bias (systems trained on skewed data perpetuating unfairness), the digital divide (unequal access to technology), and the responsibilities that come with artificial intelligence and pervasive data collection.
The environmental dimension is examined too: the energy consumption of data centres and large-scale computation, the carbon footprint of the technology sector, and e-waste — the disposal of obsolete hardware containing hazardous materials — together with the mitigations of energy-efficient design, recycling and responsible disposal. The exam skill here is structured evaluation: identify the stakeholders affected, lay out the benefits and harms on each side, and reach a justified conclusion rather than asserting one. You should also be aware that professional bodies publish codes of conduct that set ethical expectations for computing professionals. This lesson asks you to think like a responsible practitioner, applying judgement where the law alone gives no answer — the natural culmination of a course that began with how to store data and ends with what we owe to the people that data is about.
How to Revise Databases, Ethics & Law
Revise the two halves of this course with two different techniques. For the database half, practise by doing: take an unnormalised table and work it all the way to 3NF, narrating at each step which rule forces the split; write SQL from English prompts until SELECT … WHERE … ORDER BY, the aggregate functions with GROUP BY, the INSERT/UPDATE/DELETE trio (never forgetting the WHERE), and the INNER JOIN … ON pattern are automatic; and rehearse the ACID properties against the bank-transfer example so you can explain what each guarantee prevents. For the law and ethics half, learn the four statutes by name, year and purpose — the Data Protection Act 2018 with UK GDPR (personal data and its principles), the Computer Misuse Act 1990 (unauthorised access, access with intent, and unauthorised modification), and the Copyright, Designs and Patents Act 1988 (protecting original works including software) — and then drill applying them to short scenarios, since the marks come from classification and argument, not recitation.
The single most valuable habit for the ethics questions is to write balanced, stakeholder-aware answers that weigh competing interests and reach a justified conclusion, because that structure is exactly what the mark scheme rewards. When you can design and query a normalised relational database with confidence, and construct a reasoned legal and ethical argument about a computing scenario, you have met both demands this course makes. Work through every lesson in OCR A-Level CS: Databases, Ethics & Law, and continue along the OCR A-Level Computer Science learning path toward the remaining courses in the H446 series.