Skip to topic
    ← Back to course topics

    Fundamentals of databases — AQA A-Level Computer Science

    Test yourself on Fundamentals of databases with AQA A-Level practice questions.

    Start free

    7 days Premium · Then free forever · No card, no charge

    Fundamentals of databases explained

    This topic covers the fundamental principles of relational databases, focusing on conceptual data modeling and entity-relationship diagrams.

    Read the full explanation

    It also explores the practical application of SQL for data manipulation and the theoretical underpinnings of database design, including normalization to third normal form and managing concurrent access in client-server systems.

    What to demonstrate

    1. Correct identification of entities, attributes, and relationships in an ER diagram.
    2. Accurate application of normalization rules to reach third normal form (3NF).
    3. Correct use of SQL commands for data retrieval (SELECT), insertion (INSERT), updating (UPDATE), and deletion (DELETE).
    Show all 6 objectives
    1. Correct use of SQL for table definition (CREATE TABLE).
    2. Understanding of primary, composite, and foreign keys.
    3. Explanation of concurrency control mechanisms like record locks and serialisation.

    Fundamentals of databases exam tips

    Topic Overview

    Databases are fundamental to modern computing, enabling efficient storage, retrieval, and management of large volumes of data. In the AQA A-Level Computer Science specification, the 'Fundamentals of databases' topic covers the core principles of database design, including the relational model, normalisation, and SQL. Understanding these concepts is crucial for developing robust, scalable applications and for managing data integrity in real-world systems.

    This topic builds on earlier concepts of data structures and file handling, introducing students to the relational database model where data is organised into tables (relations) linked by keys. You will learn how to design a database schema that minimises redundancy and avoids anomalies through normalisation (up to Third Normal Form). Practical skills include writing SQL queries to retrieve, insert, update, and delete data, as well as creating and modifying database structures. Mastery of databases is essential for any career in software development, data analysis, or information systems.

    Databases underpin everything from online banking to social media platforms. By studying this topic, you will gain the ability to design efficient databases that support complex queries and maintain data consistency. The AQA exam expects you to apply normalisation rules, interpret entity-relationship (ER) diagrams, and write SQL statements. This knowledge also provides a foundation for further study in areas like big data, distributed databases, and data warehousing.

    Key Concepts
    • →Relational database model: data organised into tables (relations) with rows (tuples) and columns (attributes), linked via primary and foreign keys.
    • →Normalisation: process of eliminating data redundancy and update anomalies by decomposing tables into smaller, well-structured tables (1NF, 2NF, 3NF).
    • →Structured Query Language (SQL): standard language for defining and manipulating relational databases, including DDL (CREATE, ALTER, DROP) and DML (SELECT, INSERT, UPDATE, DELETE).
    • →Entity-Relationship (ER) diagrams: graphical representation of entities, attributes, and relationships used to model database structure before implementation.
    • →Transaction management and ACID properties (Atomicity, Consistency, Isolation, Durability) to ensure reliable processing of database operations.
    Marking Points
    • Correct identification of entities, attributes, and relationships in an ER diagram.
    • Accurate application of normalization rules to reach third normal form (3NF).
    • Correct use of SQL commands for data retrieval (SELECT), insertion (INSERT), updating (UPDATE), and deletion (DELETE).
    • Correct use of SQL for table definition (CREATE TABLE).
    • Understanding of primary, composite, and foreign keys.
    • Explanation of concurrency control mechanisms like record locks and serialisation.
    Examiner Tips
    • 💡Practice drawing ER diagrams from written scenarios to improve speed and accuracy.
    • 💡Memorize the properties of 3NF to ensure you can justify your normalization steps.
    • 💡Ensure you can distinguish between different types of keys (primary, foreign, composite) and their roles.
    • 💡Use clear, standard SQL syntax in your answers.
    • 💡Be prepared to explain how concurrency issues are resolved in a client-server environment.
    • 💡When normalising, always start by identifying the functional dependencies in the data. This will guide you in decomposing tables correctly. Examiners look for clear reasoning, not just the final normal form.
    • 💡In SQL questions, pay close attention to the exact wording. If asked to 'list all customers who have placed an order', you need a JOIN between Customer and Order tables. Missing the JOIN or using incorrect syntax loses marks.
    • 💡For ER diagrams, ensure you correctly identify the cardinality of relationships (one-to-one, one-to-many, many-to-many). Many-to-many relationships require a linking table. Practice drawing diagrams with clear labels.
    Common Mistakes
    • Failing to correctly identify the primary key in a relation.
    • Incorrectly mapping relationships in ER diagrams (e.g., confusing one-to-many with many-to-many).
    • Over-normalizing or failing to reach 3NF.
    • Syntax errors in SQL queries, particularly with JOIN operations or WHERE clauses.
    • Misunderstanding the impact of concurrent access on database integrity.
    • Misconception: 'Normalisation always means splitting tables until each table has only one attribute.' Correction: Normalisation aims to reduce redundancy and dependency, but over-normalisation can lead to excessive joins and performance issues. Third Normal Form (3NF) is typically sufficient for most applications.
    • Misconception: 'Primary keys must always be a single column.' Correction: A primary key can be composite (multiple columns) if no single column uniquely identifies a row. For example, in a table recording student enrolments, the combination of studentID and courseID might serve as the primary key.
    • Misconception: 'SQL is case-insensitive for everything.' Correction: While SQL keywords are case-insensitive, string comparisons in data are case-sensitive depending on the database system (e.g., MySQL's default collation is case-insensitive, but PostgreSQL is case-sensitive). Always check the specific DBMS behaviour.
    Frequently Asked Questions
    What is the difference between a primary key and a foreign key?
    A primary key is a column (or set of columns) that uniquely identifies each row in a table. It must contain unique values and cannot be NULL. A foreign key is a column in one table that references the primary key of another table, establishing a link between the two tables. Foreign keys enforce referential integrity, ensuring that values in the foreign key column match existing primary key values in the referenced table.
    How do I normalise a table to 3NF?
    To normalise to Third Normal Form (3NF), follow these steps: 1) Ensure the table is in 1NF (atomic values, no repeating groups). 2) Ensure it is in 2NF (no partial dependencies – every non-key attribute must be fully functionally dependent on the whole primary key). 3) Remove transitive dependencies (non-key attributes should not depend on other non-key attributes). This typically involves splitting the table into smaller tables, each with a clear primary key, and linking them via foreign keys.
    What SQL command is used to retrieve data from multiple tables?
    The SELECT statement with JOIN clauses is used to retrieve data from multiple tables. Common types include INNER JOIN (returns rows with matching values in both tables), LEFT JOIN (returns all rows from the left table and matched rows from the right), and RIGHT JOIN. For example: SELECT Customers.Name, Orders.OrderDate FROM Customers INNER JOIN Orders ON Customers.CustomerID = Orders.CustomerID;
    What is an entity-relationship diagram and why is it useful?
    An entity-relationship (ER) diagram is a visual representation of the entities (tables) in a database and the relationships between them. It uses symbols like rectangles for entities, diamonds for relationships, and lines to connect them. ER diagrams are useful for planning database design before implementation, helping to identify entities, attributes, and relationships clearly, and ensuring that the database structure meets requirements without redundancy.
    What are ACID properties in databases?
    ACID stands for Atomicity, Consistency, Isolation, and Durability. Atomicity ensures that a transaction is treated as a single unit, which either completes fully or not at all. Consistency ensures that a transaction brings the database from one valid state to another, maintaining all rules. Isolation ensures that concurrent transactions do not interfere with each other. Durability guarantees that once a transaction is committed, it remains so even in the event of a system failure.
    How do I choose between a one-to-many and many-to-many relationship?
    A one-to-many relationship exists when one record in Table A can be associated with multiple records in Table B, but each record in Table B is linked to only one record in Table A (e.g., one customer has many orders). A many-to-many relationship exists when multiple records in Table A can be associated with multiple records in Table B (e.g., students and courses). Many-to-many relationships require a linking table (junction table) that contains foreign keys referencing both tables' primary keys.